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MULTIMEDIA INFORMATION TRANSMISSION 
AND DISTRIBUTION SYSTEM 

Background of the Invention 

5 This invention relates to a system for the transmission of audio and combined video, 

data, multimedia programming and control signals to remote receiving locations for 
distribution under the command of the control signals. Transmission of audio and video 
signals to local receiving stations for immediate use, re-transmission or recordation for later 
transmission is a well-established practice, particularly in connection with distribution of 
10 television programming by various television networks and cable systems. Utilization of data 
to generate characters which are displayed on a video screen over a single color background 
or another video signal background is also established practice. 

These practices have been combined with new technologies to create for viewers what 
appears to be continuous programming, but is really a sophisticated stream of many types of 
15 segments, or products, originating from different places. For instance, U.S. Patent No. 

4,725,886 to Galumbeck and related U.S. Patent Nos. 4,916,539 to Galumbeck and 5,140,419 
to Galumbeck, which are incorporated herein in their entireties by this reference, disclose 
current communications systems utilizing novel hardware and software configurations to 
transmit conventional video and audio program material together with data and control 
20 commands within the constraints of conventional television signal specifications to remote 
signal processors or receivers within the system. The remote signal processors or receivers 
receive the entire transmission and process it in a predetermined manner such that the data 
and the conventional video and audio signals may be utilized at the remote receivers, under 
network control, particularly for transmission on local cable television systems. 
25 This technology may be applied to any system for distributing information and is not 

limited to weather related information; however, the application of this technology may best 
be understood by analyzing the operation of an existing system such as The Weather Channel 
(TWC). TWC is an automated system for distributing and delivering weather related 
information, or "products" over broad areas. 
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The main classes of current TWC information are local weather segments, national 
weather segments and advertisements. All are presented in different ways and at different 
times, creating a multiplicity of products. These products vary in sophistication. For 
example, a product may be a relatively simple banner of text running across the bottom of a 
5 screen; a nationwide weather presentation by an On-Camera Meteorologist (OCM) with the 
help of satellite animation; or a multiframe radar map overlay sequences provided in data 
form to the cable headend and processed there for display to local viewers overlaid on a 
geographic map to show, for instance, movement of a storm system. 

As illustrated in FIG. 1, at any time during the TWC programming day, there are two 
10 types of information which must be prepared at the TWC central facility and transmitted to 
the cable company for presentation of TWC programming: the national transmission 10, 
which is seen by all cable subscribers; and the local transmission 16, which is seen by 
viewers in selected corresponding cable markets. National transmission 10 is transmitted as a 
traditional audio/visual (A/V) signal originating at TWC headquarters 12 in Atlanta, Georgia. 
15 The same signal. carries (via subcarrier) local transmission 16, which is transmitted to the 
cable operator as data representing local weather information, advertising information and 
commands that instruct the cable headend, or receiving unit 14, on how to display the 
information. Receiving unit 14 periodically produces its own programming using the data 
sent by TWC. Receiving unit 14 passes national transmission 10 through during its time slot; 
20 however, during the time for the local transmission 16, locally-created graphics and 
programming (generated with data received from TWC) from receiving unit 14 are 
interposed. 

The conventional TWC distribution system for local weather data can be thought of 
generally as a one-way client/server architecture, where raw data and A/V are sent to 
25 receiving unit 14. Receiving unit 14 then assembles the data for display (local transmission 
16) or passes through the A/V signal (national transmission 10), depending on the 
instructions sent by TWC headquarters 12. 

As illustrated in FIG. 2, three sources of information are drawn upon to create national 
transmission 10 and local transmission 16: weather data 18, affiliate database 20, and 

2 
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programming/scheduling 22. These sources are drawn upon by many subsystems to form the 
final programming seen by the cable subscriber. 

The first source of information is data and graphics accumulated for weather forecasts 
from external sources and is collected in a system called the meteorology system 24, 
5 illustrated in FIG. 3. Not all information is passed from Meteorology system 24. 
Meteorology system 24 filters information as dictated by a local database called the 
meteorology system interest list. 

Weather data 1 8 is collected by the National Weather Service (NWS) 26. NWS 26 
has weather collection sites throughout the United States at airports, military bases, and other 
1 0 selected sites. These sites report each hour during their scheduled reporting time, which 

varies from six to twenty-four hours depending on requirements. Some sites are automated, 
while others are manual, with information being collected and presented either by machine or 
by personnel at the site. 

A third party provider 28, disseminates that information to TWC in tabular and 
1 5 narrative form. Tabular data 30 is presented in fixed-length records with fixed-length fields 
or specific weather conditions. Character fields are typically left-justified and either 
maximum length or null-terminated. Numeric fields are either binary or right-justified with 
leading spaces. For example: 



Location 


Temp 


Description 


Etc. 


ATL 


75 


SUNNY 


ETC. 



20 This information arrives at any time and typically includes information such as the 

temperature, wind speed, humidity and other weather related information for a particular 
location. 

Other information provided by the weather reporting agencies includes weather 
warnings and advisories, which are provided as narrative data 32 in free-form text as variable 
25 length strings. Radar maps 34 are provided by the National Oceanic and Atmospheric 

Administration (NOAA) in run-length encoded form and are converted into a composite and 
sent to the field every fifteen minutes. Backup system 36 is provided in the event data cannot 
be received from TWC. 

3 
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Referring to FIG. 2, to correctly route the information, affiliate database 20 
stores the location and address of the cable operator (or the cable operator's equipment in 
cases where there may be multiple headends installed). Affiliate database 20 contains 
information needed to transmit weather data to cable operators. Much of the information 
5 focuses on reconciling a cable operator's zip code with their geographical longitude and 

latitude. This allows the information to be addressed to an appropriate location, so that, for 
instance, weather information relevant to Miami will be directed to the Miami receiving unit. 
This also allows tags and copy splits to be directed to the desired location. Tags are 
billboards appearing at the end of a commercial. They display the name and address of the 
10 local operator of a national company. For example, a Michelin Tire commercial could list the 
names of the local dealers. A copy split could include different commercials for different 
areas of the country. 

Programming 22 includes information, advertisements, program direction, and camera 
assignments. Production is fully automated: cameras, sets, commercials, and weather data are 

15 presented on a predetermined schedule. OCM segments and other live action A/V are 
produced in an automated studio where the operation of cameras and other production 
equipment are controlled by an automated production engine 38. Production engine 38 
creates and coordinates the live A/V transmission and command data feed. 

FIG. 4 illustrates how information for this programming is directed into production 

20 engine 38. Entry of programming information to the system begins with the sale of 

commercial advertisements and sponsorships of programming. Sales proposal system 40 
identifies and tracks potential customers. Also, sales are proposed and secured with 
contracts. Commercial contracts are entered into traffic system 42 by department personnel. 
Traffic system 42 classifies the terms of the contract. An advertisement schedule is then 

25 transferred to traffic system 42. Traffic system 42 also contains the programming schedule 
for TWC and, as such, the first draft for a programming day is developed there. In addition, 
traffic system 42 is the main scheduler, where the script is written for the programming day, 
including advertisements and schedules for national 10 and local 16 transmissions. A video 
tape of the commercial is loaded into a large videotape tower carousel 44, such as an Odetics. 

30 The stored commercials are then played according to a schedule log. 
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The Source Book program on computer 46 converts the commercial schedule from 
traffic system 42 into the schedule log. It coordinates the schedule with the computer 
commands to be sent to all equipment involved in the transmission period. Once compiled 
this file is transferred from computer 46 to production engine 38 and tape carousel 44. 
Technical Directors at the production engine Edit Station perform any necessary real-time 
modifications. 

The Source Book program produces OCM Guide Sheets 48. It produces hard copi 
of the schedule log specifically for the OCMs. This log then becomes the production script 
for live weather transmissions. 

Referring to FIG. 2, production engine 38 also directs command data 50 to host 52. 
Weather data 1 8 and affiliate data 21 arc combined with command data 50 to create the final 
command transmission 53 (provided by host 52), and a live A/V transmission 54 is created 
simultaneously. Next, command transmission 53 and the live transmission 54 are combined 
into one transmission 56. Transmission 56 is beamed via satellite to most of the cable 
1 5 operators in the US. Transmission 56 is captured by a satellite dish, decrypted by 

conventional decryption means such as General Instruments Videocypher II equipment and 
broken into its component parts — command data and video — and then sent to receiving unit 
14. 

Receiving unit 14 uses the information carried in the signal to produce the 
20 presentation seen by viewers and to pass-through audio and video. To accomplish this task, 
receiving unit 14 receives the national transmission 10 and a stream of command, advertising 
and weather data. When receiving unit 14 is instructed to pass-through national transmission 
10, it directs the video signal, i.e., the national transmission, from the TWC to the cable 
operator's network, where it is seen by viewers. When instructed to show the local 
25 transmission 1 6, receiving unit 1 0 combines data and onboard graphics to produce local 

transmission 16. The pass-through of national transmission 10 is then interrupted and local 
transmission 16 is forwarded to the cable operator's network, where it is seen by viewers. 
Receiving unit 14 is capable of building graphics by running a custom scripting language. It 
can perform color shifts and simple radar map animations. The end result is that the cable 
30 subscriber receives programs formed of segments of national 10 and local 16 transmissions. 



BNSDOCID: <WO 9815122A1_I_> 



WO 98/15122 



PCT/US97/17412 



Referring to FIG. 5, one of the most important aspects of the current TWC system is 
the relationship between receiving unit 14 and host 52. Host 52 communicates with receiving 
unit 14 by sending commands. The commands either configure receiving units 14 or prepare 
and execute local transmission 16 (including programming such as advertising information). 

There are two lines of communications between production engine 38 and host 52. 
First, there is a data communications line 58 between host 52 and production engine 38. As 
previously mentioned, production engine 38 produces the program day's schedule in its final 
form. Data tine 58 sends an event list and ensures that production engine 38 and host 52 are 
synchronized. The second form of communications is the Take Line. This is a binary switch 
(5 volts = on, -5 volts = off) that instructs host 52 to initiate the next event. 

In general, local weather is transmitted several times each hour; however, weather 
warnings or remote reports may be scheduled in an ad-hoc manner. Thus, the TWC system 
must be able to respond accordingly. In order to produce the desired programming, receiving 
units 14 typically respond to at least three command sets: cyclic, load and run. The task with 
the lowest priority is the cyclic command, which runs during each hour and sends all the 
configuration data needed to re-initialize receiving units 14. The cyclic command set is 
intended to refresh a receiving unit 14 that has lost power or been replaced. The cyclic 
command set is important because no current receiving unit 14 has any significant amount of 
permanent storage capability. The only storage provided consists of random access memory 
(RAM), backed up by a battery power supply. If the batteries fail, the configuration 
information is lost. 

Another important command sent to receiving units 14 is the load command set. The 
load command set warns receiving units 14 of an impending local transmission 16. This 
allows time for loading the presentation into memory to eliminate delays in the transition 
from national 16 to local 10 transmissions. 

After the load command set has been executed, the run command set is sent. This 
causes receiving units 14 to cut off national transmission 10 and begin local transmission 16. 
Three components of the run command set are: sensors, commercials and tags. The sensor 
component instructs those receiving units 14 that have weather sensing equipment attached to 
read those devices. The commercial component allows receiving units 14 to run local 
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commercials. Upon receiving the run command, receiving units 14 signal local video 
equipment to run and turn off national transmission 10. The tag command instructs the 
receiving units 14 to produce a text output over or after a national commercial, thereby 
advertising local outlets. 

Of course, these systems can be used to create all forms of programming and are not 
limited to weather-related information. For instance, educational, sports, entertainment, 
business, product marketing and other forms of information can be distributed in this manner. 
Furthermore, this system may be used to distribute information over media other than 
televisions, for instance, home computers. Nonetheless, these systems have several 
limitations which limit the quality and character of programming that may be displayed to the 
viewer and the flexibility with which product can be distributed on a national and local level. 

In particular, bandwidth availability may limit the volume of information which may 
be transmitted to the various receiving units. Although compression technology has 
significantly expanded the amount of information that may be transmitted over a given 
15 channel, consumer demand for more information and increasing sophistication of multimedia 
products has caused even greater growth in the total volume of information which must be 
transmitted to create the ultimate program received by the viewer. One solution is simply to 
increase the number of channels used to transmit the information; however, rapid expansion 
in the number of content providers has limited the availability of additional channels (as well 
20 as increasing the cost of existing channels). This problem affects not only conventional 
communications channels, such as satellite transmission, but also more recently available 
channels, such as the Internet. Thus, it is desirable to limit the bandwidth required to transmit 
a given set of information by providing a system which coordinates the transmission of 
information in its various forms, i.e., analog and digital video and audio, data, etc. to 
25 maximize the utilization of the available channels and therefor the through-put. 

The hierarchical addressing system as taught in the Galumbeck patents can limit the 
flexibility of product distribution over discrete areas. This is because the current scheme 
requires that a separate message be sent to each receiving unit unless the message is common 
to all of the receiving units within a given tier of the hierarchy. For example, a single 
30 message cannot be sent to only the receiving units in Miami and Los Angeles unless it is 
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desrred that all other receiving units within the same tier display that same message. If the 
message is only intended for Miami and Los Angeles, two separate messages must be sent. 
Due to the limited availability of bandwidth and transmission channels, the total number of 
messages being sent over a given period may be limited, often making it difficult or 
5 impossible to send individual messages to discrete receiving units. 

Nonetheless, it may be desirable to send messages to individual receiving units based 
on non-hierarchical criteria. The current hierarchical structure is based on geographical 
boundaries, which is consistent with the needs of displaying weather data; however, other 
criteria for distributing information may be envisioned. For instance, it may be desirable to 

10 target distribution based on demographics for advertising purposes, e.g., locations with high 
proportions of retirees or males 18-24, etc. Thus, it would be desirable to provide a system 
for sending a single message addressed to multiple receiving units on a non-hierarchical basis 
without necessarily incorporating other, undesired receiving units. 

The current system distinctly segregates A/V transmission and data transmissions. 

15 The data transmissions are handled by the product server/host/receiving unit system (the 

"command data system' 1 ) while the A/V transmissions are handled by the production system, 
production engine 38 coordinates both signals to create the final sequence of products 
displayed to the viewer. It may be desirable to provide A/V data which can be displayed on 
the local rather than the national level; however, the current receiving unit does not have the 

20 capability of recording and replaying such large blocks of data. Furthermore, the command 
data system is not capable of producing and transmitting A/V data. Also, the production 
system is not capable of transmitting addressed data. Therefore it would be desirable to 
provide a system which can coordinate the transmission of an address through the command 
data system and the transmission of local A/V through the production system to a receiving 

25 unit capable of recording the local A/V and re-distributing it as is currently done with data. 

The current receiving unit 14 may be accessed from the host via the transmission 
system as well as other means, including modems and the Internet; however, the multiplicity 
of communications protocols limits the flexibility of these communications. Also, it is 
difficult to coordinate multiple lines of communications to perform advanced functions such 

30 as monitoring of transmission reception via an Internet link. Thus it would be desirable to 
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create an integrated communication system which allows the host to use a single interface 
regardless of the communications topology that is being used to communicate with the 
receiving unit. 

The command data system comprises multiple hardware and software elements. Each 
5 of these elements must communicate effectively in order to ensure system functionality. As 
system complexity increases, however, it becomes increasingly difficult to maintain the 
integrity of inter-module communication, especially as particular elements are upgraded or 
replaced. Thus, it would be desirable to provide a standardized interface between the 
elements which allows data to be transmitted there between and allows an appropriate level of 

1 0 error checking to be used. 

The current receiving unit can only perform limited manipulations of the data it 
receives. It would be desirable to provide a receiving unit which can perform advanced data 
manipulation. Performing more advanced manipulation requires a more sophisticated 
operating system and system diagnostics. Therefore an advanced receiving unit must also be 

1 5 capable of performing advanced housekeeping functions. 

The current system relies on the production system and the meteorology system to 
provide the vast majority of products such as weather alerts and data formatting. This 
requires large amounts of data to be repeatedly transmitted. It would be desirable to provide 
the receiving unit with sufficient intelligence to perform much of the data formatting, such as 

20 plotting data on map-like representations and other advanced features such as identification of 
notable weather anomalies or patterns and independent product selection. 

The current receiving unit presentation file is built and played at the same time, 
leaving these systems idle for most of the programming hour, then forcing them into a high 
state of utilization for the local weather transmission. Because the current receiving unit must 

25 "Build and Play" concurrently, it is limited by horsepower (as to the sophistication of its 

graphics) and by the desire to use the latest data. "Build and Play" is a requirement of these 
systems because of the lack of permanent storage limited their ability to build and store a play 
file. Thus, it would be desirable to provide a system that can store data and selectively 
retrieve and process that data in a manner that more effectively and efficiently uses the 

30 available resources, e.g., processor time, storage space, etc. 

9 
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Summary of the Invention 

The present invention relates to a system which provides these desired functions and 
capabilities. 

5 Addressing schemes according to the present invention allow more flexibility in 

programming individual receiving units. The information may be, for instance, segregated 
between individual receiving units in the following manner: Each receiving unit has an 
interest list which can be, for instance, a table of two columns, the first of which bears a field 
name and the second bearing a field value. Thus, a receiving unit in Cobb County, Georgia 

10 may have a field name of "state" and a field value of ''Georgia," a field name of "county" and 
a field value of "Cobb," and so forth, for any variety of selection criteria that may be desired. 
The criteria need not be geographic. For instance, one criteria may be a field name of 
"demographic area 1" which represents an area with a high number of retirees, A field value 
of "1" or "0'' indicates that that receiving unit is or is not a member of "demographic area 1 ." 

15 Thus, completely disparate receiving units in different regions may be "interested" in similar 
information due to factors other than geography. 

At the transmission source, a product server formats the data, introducing an address 
which may be formatted in structured query language (SQL). For instance, a set of data may 
begin with the command "select receiving unit where County = Cobb." The next line of 

20 information begins "weather information equals" followed by a string of data. Each receiving 
unit looks at the incoming information and if the address data matches the interest list, in 
other words, if "county = Cobb," it then proceeds and reads the rest of the data and formats it 
for display. If it is not true, the information is simply disregarded. 

This allows the system to be different from conventional systems in at least the 

25 following manner. The current system uses a hierarchical addressing scheme. In other words 
data may be delivered only to ever expanding unitary regions. Thus, data may be sent to the 
receiving unit in the City of Atlanta or all of the receiving units in Cobb County, Georgia 
which might include the receiving unit in the City of Atlanta or all of the receiving units in 
the State of Georgia which will include all of the receiving units in Cobb County and the City 

30 of Atlanta. It is impossible, however, to send a single message to be received by both a 

10 
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receiving unit in Atlanta and a receiving unit in San Francisco without the same message 
being received by all of the receiving units in the same common region, for instance, the 
United States. 

It may be desirable, however, to address one message to separate receiving units in 
5 distinct geographical regions without capturing the smallest common region between those 
two points. For instance, it may be desirable to direct targeted programming to a particular 
demographic sample such as the elderly or the retired in the cities of Phoenix, Miami and Los 
Angeles. However to do so with the current system would require that three separate 
messages be sent, even though the data being sent is identical, in order to be addressed to 
10 those particular receiving units without including the intervening common region and all of 
the receiving units included therein. The addressing system of the invention allows a single 
message to be targeted to numerous disparate locations without capturing unwanted receiving 
units. Thus the addressing list for a piece of data targeted at receiving units with particular 
demographics may be accomplished simply by including that criteria on the receiving units' 
1 5 interest list and then addressing the information accordingly. 

Both the current system and the new system transmit to the receiving units by means 
of a single transmission channel which carries multiple channels, e.g., four audio channels 
and one video channel. This video channel and one of the audio channels may be dedicated 
to the national programming. One of the audio channels provides the background music for 
20 data displays and one of the audio channels provides the command feed to the receiving units. 
The last audio channel provides digital command data. Other numbers and combinations of 
audio and video channels may be selected as appropriate. 

Systems according to the invention have the ability to send local voice-over audio 
signals, that is, a narration for the local transmission. Also provided are local video 
25 downloads. In other words, instead of simply directing data to particular regions, audio and 
video may also be provided selectively to different regions. In order to do this, a portion of 
the satellite transponder system is taken and the modulation is narrowed to allow the addition 
of one or more sub-carriers. Alternatively, more transponders may be used, increasing total 
available bandwidth. 

11 
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In order to provide the video and voice-over information to the receiving units, a 
master dynamic scheduler (MDS) may be provided. Addressing information for data and the 
data itself can thereby be sent over separate channels. In the current system, the national 
transmission is produced in the production system as controlled by the automation system and 
sent directly through the receiving unit to the viewer. The local transmission is created by the 
command data system and the data is sent to the receiving unit and stored, processed, and 
displayed periodically. The decision by each receiving unit to store particular data is based 
on the addressing information. 

According to the invention, voice-over and video information can be produced in the 
studio, which may controlled by the automation system, forwarded to a storage system and 
periodically transmitted, under the control of the automation system, in digital compressed 
form to the receiving units. The form in which it is transmitted, however, is not addressed. 
Instead, addressing information is sent out from the host, which commands the receiving unit 
to, for example, "look at digital channel one and record information for the next 2 minutes." 
The MDS coordinates the automation system and the host so that the message instructing the 
receiving units when to begin recording comes at the proper time so that the data is not 
missed. 

Thus, a video and voice-over intended for a particular locality, such as Miami, may be 
prepared. The host then sends a message addressed to the Miami receiving unit which tells it 
to look at the first digital transmission line and to store the next 2 minutes of data that is 
being fed through. At the same time, the automation system begins transmitting the video 
data. The MDS coordinates these two devices so that the timing is worked out. The MDS 
also knows to avoid conflicts. For instance, if the receiving unit cannot record video data and 
play back video data at the same time, the MDS knows at what times video is being played 
back by a particular receiving unit and avoids sending data to that particular receiving unit at 
that time. The MDS is aware of what each receiving unit is doing at any particular time and 
selects data from the transmission queue for delivery in a way that avoids functionality 
conflicts while optimizing the use and capacity of the delivery medium. An alternate 
embodiment includes recording the data in digital form and also providing it with an address. 
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Another embodiment includes foregoing the digitization and compression of video data 
feeding it to the receiving unit in real time for immediate playback to the viewer. 

Furthermore, use of the MDS allows the throughput of the transmission channel to be 
maximized. By prioritizing data, transmitting at appropriate times and identifying 
"downtime" in which to transmit low priority data, the transmission channel can be kept 
"full" at all times. This approach allows as much as possible of the channel bandwidth to be 
used before additional bandwidth must be secured. In other words, rather than rigidly 
scheduling transmission times, much of the information which is not real-time or high 
priority may be delayed until bandwidth becomes available. Additional bandwidth becomes 
necessary only when the entire channel is consumed over such long periods of time to make 
transmission delays impractical. This has the effect of dramatically increasing the total 
transmission capacity over a given period of time. 

In order to effectively manage the data flow, however, the MDS must know the status 
of each and every receiving unit which it controls. Where a two way link is available, such as 
1 5 over the Internet, the MDS may simply query each receiving unit to determine its status (for 
example, this is necessary to avoid sending data to be recorded to a receiving unit when the 
unit is already playing back recorded data, since the recording and playback functions may 
conflict). When the only available link is one way, such as satellite transmission, the MDS 
must maintain a "mirror file," that is, a record of all information that has been delivered to 
20 each receiving unit. In this manner, the MDS knows the remaining storage capacity of each 
unit and its playback schedule, allowing data transmissions to be scheduled for maximum 
efficiency. 

One limitation of the system is that the satellite link between the transmission facility 
and the receiving units only supports one way communication from the transmission facility 

25 to the receiving units. If this were the only link available, it would be impossible to monitor 
the receiving units and to conduct diagnostics to determine whether information was being 
properly delivered. Thus receiving units are equipped with additional ports for 
communications, such as RS232 ports for modem access and TCP/IP ports for Internet 
access. In this manner, the operator may contact each of the receiving units through these 

30 other means and have two way communications that allow diagnostics, monitoring and other 
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tasks. Additionally, receiving units may receive transmissions over the internet, but be 
serviced via a direct modem link. 

One problem, however, is that three or more communications protocols may be 
necessary, each required to support one means of communications. One standard protocol is 
5 provided for satellite delivery to the receiving unit, a second for modeming to the receiving 
unit and yet another for Internet communications with the receiving unit, etc. Thus it would 
be desirable to provide a consistent interface to the user regardless of what topology is used to 
communicate with the receiving unit. This is accomplished by providing a TCP/IP overlay, 
which connects to the receiving unit. The "underbelly" of the overlay is a socket which 

10 connects to as many communication protocol "translators" as necessary to support the 
selected means of communications. 

Similarly, each element of the system includes sophisticated software components. 
Each of these components must communicate effectively with the others so that the system 
can function properly. A system according to the invention provides software "plugs" which 

1 5 are standard interfaces between software components. These interfaces allow standardization 
of communication protocols between components. Furthermore, features, such as error 
checking, may be incorporated in the plug. 

Receiving units according to the invention incorporate a software structure which 
includes three layers: command, hardware and presentation. The command layer accepts all 

20 data and determines whether the data is addressed to the particular receiving unit. If so, the 
data is either sent to the hardware layer, which is responsible for carrying out housekeeping 
tasks such as debugging and defragmentation, or to the presentation layer, which manipulates 
the data and prepares the product seen by the viewer. This modular approach allows for 
flexibility in programming and maintaining the receiving unit. 

25 Receiving units according to the invention may have advanced capabilities for 

manipulating and formatting the data. Instead of simple graphics and static icons, many 
video effects, such as text scrolling, video fades, animated icons, screen squeezes, etc. are 
provided. 

In a system according to. the invention, for particular forms of information only certain 
30 data related to the product are actually transmitted. For instance, for radar maps, the basic 

14 



BNSDOC1D: <WO. 



.98151 22A1J_> 



WO 98/15122 



PCT/US97/17412 



10 



information relating to the region to be displayed, e.g., a topographic map of the United 
States and an overlay map showing the geographical boundaries, are stored by the receiving 
unit. Additional overlay information showing the actual radar data is sent out over the 
system. The receiving unit is given information to know its own location by latitude and 
longitude. The receiving unit selects the portion of the map corresponding to its location and 
a predetermined surrounding area and displays only that portion of the map and its 
corresponding radar data. 

Receiving units according to the invention may have a artificially intelligent program 
for scanning the weather data in making projections based thereon. For instance, the 
receiving unit may analyze the data used to construct a radar image and, if certain criteria are 
met, such as high intensity precipitation in conjunction with other factors, the receiving unit 
may issue a severe weather alert regardless of whether the National Weather Service has done 
so. 

Likewise, receiving units according to the invention may intelligently "select" 
1 5 products. For instance, a receiving unit in a landlocked region knows to display an Almanac 
product instead of a Tides product. Similarly, receiving units according to the invention 
analyze incoming data and, based on selected criteria, generate new products which highlight 
significant aspects of the data. For instance, the receiving unit may analyze the incoming 
radar data to identify regions of high pixel intensity and density which would indicate severe 
20 weather. The receiving unit may then generate a weather advisory product for the affected 
area. 

The receiving unit according to the invention also responds to a loss of signal by 
generating its own playlist and operating until the signal is recaptured. 

Accordingly, it is an object of the present invention to provide a multimedia 
25 transmission and distribution system which increases the ability of each receiving unit to be 
highly customized on a localized basis. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which maximizes information throughput over a given transmission 
channel thereby minimizing the number of channels necessary to deliver the product. 
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Another object of the present invention is to provide a multimedia transmission and 
distribution system which de-links the overall system from the receiving unit software - i.e., 
makes the software accommodate the spectrum of localization. 

Another object of the present invention is to provide a multimedia transmission and 
5 distribution system which eliminates much of the time for dispatching configuration data so 
that more sophisticated and specialized data can be delivered in its place. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which accommodates the current strategy of building a presentation from 
data and visual effects in a way that allows for more advanced pre-built presentations to be 
10 downloaded and displayed. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which accommodates value-added "for-profit" services such as local 
advertising. 

Another object of the present invention is to provide a multimedia transmission and 
1 5 distribution system which facilitates the use of off-the-shelf presentation products. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which allows remote retrofit of presentation and housekeeping software. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which allows a consistent communications interface between the host and 
20 the receiving unit regardless of the method of communication used. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which has a non-hierarchical addressing system, i.e., that allows a single 
message to be delivered to multiple receiving units in different regions without capturing all 
receiving units the region common to the selected receiving units. 
25 Another object of the present invention is to provide a multimedia transmission and 

distribution system which allows local, but un-addressed, data to be recorded and/or 
processed by selected receiving units. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which includes software plugs between software modules to allow 
30 standardized intermodule communications and error checking. 
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Another object of the present invention is to provide a multimedia transmission and 
distribution system which allows presentation of data with state of the art graphics and video 

effects. 

Another object of the present invention is to provide a multimedia transmission and 
5 distribution system which can intelligently plot data onto on-board graphic "base maps." 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which can independently interpret downloaded data and create new 
products based on the content of the data. 

Another object of the present invention is to provide a multimedia transmission and 
1 0 distribution system which can independently select products based on local criteria. 

Another object of the present invention is to provide a multimedia transmission and 
distribution system which can operate in the absence of command data or input signals. 

Other objects, features, and advantages of the present invention will become apparent 
with reference to the remainder of the written portion and the drawings of this document. 

15 

Brief Description of the Drawings 

FIG. 1 is a block diagram of a conventional video and data distribution system 
illustrating the transmission path of the national and local transmissions. 

FIG. 2 is a block diagram of a conventional video and data distribution system 
20 illustrating the flow of information through the production system. 

FIG. 3 illustrates the structure of the Advanced Weather Graphics System of a 
conventional video and data distribution system. 

FIG. 4 illustrates the structure of the production engine of a conventional video and 
data distribution system. 

25 FIG - 5 illustrates the flow of data through the host of a conventional video and data 

distribution system. 

FIG. 6 illustrates a scheme for providing additional transmission band width in a 
multimedia transmission and distribution system according to the present invention. 
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FIG. 7 illustrates the portion of a multimedia transmission and distribution system 
according to the present invention which is responsible for creating and distributing the 
programming. 

FIG. 8 illustrates the portion of the system of FIG. 7 which is responsible for 
5 receiving the programming. 

FIG. 9 illustrates the configuration of the product server of the system of FIG. 7. 

FIG. 10 is a functional object map of the system of FIGS. 7-8 which illustrates the 
C++ classes and objects and their interrelationships. 

FIG. 1 1 is a structural object map illustrating the relationship between the components 
10 of and the flow of data through the system of FIGS. 7-8. 

FIG. 1 1 A is a structural object map illustrating the relationship between the 
components of and the flow of data through the host and product server of FIG. 1 1 . 

FIG. 1 IB is a structural object map illustrating the relationship between the 
components of and the flow of data through the product posting module of FIG. 1 1 . 
15 FIG. 1 IC is a structural object map illustrating the relationship between the 

components of and the flow of data through the host module of FIG. 1 1. 

FIG. 1 ID illustrates the structure of a command message as utilized by the system of 
FIG. 11. 

FIG. 1 IE is a structural object map illustrating the relationship between the 
20 components of and the flow of data through the queue server module of FIG. 1 1 . 

FIG. 1 IF is a structural object map illustrating the relationship between the 
components of and the flow of data through the command module of FIG. 1 1 . 

FIG. 1 1G is a structural object map illustrating the relationship between the 
components of and the flow of data through the de-queue module of FIG. 1 1 . 
25 FIG. 1 1H is a structural object map illustrating the relationship between the 

components of and the flow of data through the command abstraction layer of FIG. 1 1 . 

FIG. 12 is a functional object map of the socket classes of the system of FIG. 1 1 . 

FIG. 13 illustrates the structure of the software plugs of the system of FIG. 1 1. 

FIG. 14 is a functional object map of the packet classes of the system of FIG. 1 1. 
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FIG. 1 5 is a functional object map illustrating the data base abstraction definitions of 
the system FIG. II. 

FIGS. 16 and I6A illustrate the dynamic information strategy employed by the system 
of FIG. 11. 

5 FIG. 1 7 is a functional object map of the host of FIG. I 1 . 

FIG. 1 8 is a flowchart showing the flow of information through the ingesters of FIG. 

11. 

FIG. 19 is a flowchart showing the flow of information through the product posting 
module of FIG. 11. 

10 20 is a flowchart showing the flow of information through the host module of 

FIG. 11. 

FIG. 21 is a flow chart showing the flow of information through the command module 
of FIG. 11. 

FIG. 22 is a functional object map showing the structure and classes of the receiving 
15 unit of FIG. 11. 

FIG. 23 illustrates the software structure of the receiving unit of FIG. I I 

FIG, 24 is a flowchart showing the flow of information through the common 
application layer of the receiving unit FIG. 1 1. 

FIG. 25 is a flowchart showing the flow of information through the hardware 
20 abstraction layer of the receiving unit FIG. 1 1 . 

FIG. 26 is a flowchart showing the flow of information through the presentation 
application layer of the receiving unit FIG. 1 1. 

FIG. 27 illustrates the file structure of the receiving unit of FIG. 1 1 . 

FIG. 28 illustrate the fields used in data records used by the system of FIG. 1 1 . 
25 FIG. 29 illustrates the data types used by the system of FIG. 1 1 . 

FIG. 30 is a table of common application layer commands used by the system of FIG. 

11. 

FIG. 31 is a table of presentation engine layer commands used by the system of FIG. 

11. 

30 
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Detailed Description of the Invention 

Figures 7-8 schematically show a multimedia transmission and distribution system 9 
consistent with the principles of the present invention. They should not be viewed as 
limiting, but rather to disclose in detail one particular way for carrying out the invention. 
5 Although the embodiment disclosed hereunder is directed to a system for the transmission 
and distribution of weather related multimedia programming, the invention may be used to 
distribute many different forms of information, including, but not limited to, sports, 
education, entertainment, business and commercial programming, data and other information. 

10 Types of D ata Transmitted 

Data types have important ramifications with respect to the function and capacity of 
hardware involved in processing, transmitting and distributing information. Data types may 
be defined based on three criteria: Lossiness, Average Size, and Real-Timeliness. 

Lossiness refers to the degree to which data degradation (e.g., due to compression) 
15 will be tolerated by system 9. Lossless data cannot tolerate any data degradation. Lossy data 
can tolerate some degradation. Average size of the file is generally computed in megabytes 
and is relevant because the conduit (the "pipe") through which the data is transmitted is often 
limited. Thus, larger files may require special handling considerations. Real timeliness refers 
to the urgency of the data. Thus, a severe weather alert is urgent, whereas an upgrade to an 
20 infrequently used software utility may not be urgent. 
Data may be divided into four classes: 

• Class A Data 

Binary Lossless: Usually under 1MB. This type of data normally consists of command 
strings, tabular, and narrative weather data, and relatively small bitmaps such as the national 
25 weather map. It is not generally acceptable for data to be lost in the compression and 
processing of this data. 

♦ Class B Data 

Single Variable Frame Lossless: Large files, such as bitmaps and programs. Again, it 
is not generally acceptable for data to be lost in the compression and processing of this data. 

20 



BNSDOCID: <WO 9815122A1J_> 



WO 98/15122 



PCTAJS97/17412 



• Class C Data 

Digital Audio/Video Lossy: Large audio and video clips. These files require large 
amounts of storage space and normally must be compressed, which may cause the data to be 
changed and perhaps degraded to an acceptable extent in the process. 
5 • Class D Data 

Analog transmissions. 

These data types reflect the increased flow of data to receiving unit 14. This flow 
requires increased space and transmission lines. To achieve the needed pipe size, current 
bandwidth may be manipulated to allow more data transmission without affecting current 
10 transmission reception. Signal processors snip the ends off of the current bandwidth and send 
compressed data through the two ends. FIG. 6 illustrates such a strategy. Also, as described 
more fully below, a dynamic scheduling system may be employed to maximize utilization of 
the pipe. Other means of providing increased transmission capacity may be employed as 
appropriate. 

15 

Data Generation 

The sources of the information to be transmitted and distributed are national 
transmission 60, weather (via met system 66), and scheduling 64. National transmission 60 
runs continuously, whether it is live or pre-produced. This is necessary because not all cable 
20 operators have receiving units 14 for local weather transmissions. Also, some viewers have 
their own satellite dishes or direct broadcast systems and do not receive local transmissions. 
In these cases, the cable operators and viewers continue to view the national transmission 60 
throughout the programming day. 

System 9 treats all programming segments, including advertisements, as products. 
25 Product development system 62 provides the mechanism by which these products are created 
and introduced into the system. Examples of products that may be displayed include: radar, 
current conditions, 36-hour forecast, regional observations, regional forecast, almanac, 
extended forecast, tags, copy splits, custom products. Of course, because the system may 
also be used to distribute non-weather information, any number of products may be 
30 envisioned. For instance, a sports channel may display game statistics, scores, etc. 
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Traffic system 64 provides the template for production and advertisement schedules 
for the programming day. This template is delivered as a static file and is made real-time by 
real-time source book 78. 

Weather observations arrive from met system 66 and are delivered to product server 
5 76 where they are ingested, addressed (via data supplied by AIMS), logged, and forwarded to 
host 52 and the Voice-Over Support System (VOSS) 77. Product server 76 feeds data to the 
in-house receiving unit (via 10 based "T" connection or over its own network) 

VOSS 77 provides system 9 with a means for allowing the presentation of graphics 
and speech to be synchronized and delivered to selected receiving units 14. This technology 
10 allows the operator to produce and deliver market specific audio forecast presentations to air 
during local transmissions 16. 

To record audio transmissions, the On-Radio Meteorologist (ORM) requires 
equipment to record, store, and transfer audio. This is performed by digital audio sampling 
device 104 (essentially a computerized tape recorder), such as an Enco Audio System. 
15 Device 104 allows audio mixing; recording from a number of sources; and the storage, 

compression, playback, and transfer of audio files. Device 104 is used to record and playback 
voice files. Device 104 in voice booth 102 is used to record and pre-view voice files. 
Device 104 is used for playback of voice files to air. 

The ORM requires local weather information from met system 66. VOSS 77 feeds 
20 this information to the ORM in an easy-to-access manner, so that the data can be read into the 
device 104. Voice booths 102 are used to record local transmissions 16. and provide another 
source of information. They are supplied with equipment to record transmissions and provide 
local meteorological information to the meteorologist. The workstation in voice booth 102 
has the same functions as the prep station (not shown). 
25 The prep station allows the user to view any products supplied to system 9 by met 

system 66. The prep station is responsible for preparing scripts which are supplied to product 
server 76. The scripts specify the components and the duration for a selected local playlist. 
Once the playlist is prepared, the prep station downloads the script to product server 76. All 
narrative text editing takes place at met system 66. Met system 66 feeds data to product 

22 



BNSDOCID: <WO_ 



_9815122A1_I_> 



WO 98/15122 



PCT/US97/17412 



10 



15 



server 76. The user in the voice booth has the ability to access narrative, tabular, graphic & 
imager)' information from met system 66. 

VOSS 77 is adapted to address and continuously receive data for specific markets. 
When voice booth 102 sends out a request, VOSS 77 acknowledges the request and runs the 
file. The output of VOSS 77 is then monitored by the user in voice booth 102. MDS 68 
monitors the automation playlist in order to schedule the playlist transmission to specific 
local markets. 

Automation system 72 controls and manages the playlist and triggers device 104 and 
host 52 for field recordings and playback. Host 52 is the real time engine that controls the 
scheduling and execution of products to be displayed on receiving unit 14. 

Affiliate database 20 connects directly to product server 76. Affiliate database 20 
maintains the integrity of the affiliate information in the product server's database. This 
allows ail other applications to view this as one logical database. 

VOSS 77 may be programmed via a graphical user interface in the following manner- 
Screen One allows the selection of the city to be edited for a particular presentation. 
This is a drop down window feature that allows scrolls through the cities loaded in the 
system. The operator scrolls through the menu by using the up and down arrows or by 
moving the slide bar with mouse. Once the city is selected, the operator may press enter or 
double click the mouse to select the city. After a city is selected a window appears. In that 
window there are three options to choose from. (1) metro forecast; (2) county specific; (3) 
Head-end specific. Once the selection is made, the interface advances to the next screen. 
Screen Two offers two functions: 

a) Selection of the playlist to be prepared; and 

b) Pull-up the playlist by typing a file name. 

The pre-programmed playlist includes market specific alpha, beta, gamma, delta, and 
sigma files. 

Screen Three is in a spread sheet type format. The operator has the ability to edit, 
delete, or insert on any field necessary. The fields and their functions include: 

a) Flavor type - Header title indicating the sequence of products or "flavor" being 
30 prepared. 
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b) City - Indicates the city for which the forecast is being prepared. 

c) Head-end address - Indicates the receiving units 14 that will receive product 
and audio data. 

d) Expiration time - Indicates the expiration time of a playlist. This time stamp is 
5 embedded in the product data stream. 

e) Total duration - Shows the total run time of the playlist. 

f) Duration field - Shows the duration of a product in a playlist. This is a 
changeable field. 

g) Product type - Indicates the type of product (e.g. current condition page). 

10 h) Notify field - In this field it may be determined whether the operator or talent 

is alerted when special weather conditions are transmitted. 

i) Product ID - Indicates the type of product via its ID number (e.g. AL001X = 
Almanac). 

j) Priority field - Allows the operator to assign a priority for the transmission of a 
15 playlist (e.g. 3=normal, 2=high, l=highest). 

k) Time slot - This allows the operator or talent to choose the forecast they want 
the playlist to preempt. 

1) Pre-load - Allows staging of the playlist. 

m) Record - A GPI trigger that takes the interface to the countdown window (4) 
20 and simultaneously trigger device 104 to record and start the playlist sequence. Device and 
the playlist should not fire until the clock reaches zero. 

n) Save - Allows saving of the playlist to a file name for recall at a later time, 
o) Quit - Takes the user back to screen # 1 . 

Screen Four appears when "record" is executed (in screen 3). The system switches to 
25 screen 4 and starts the countdown sequence. At zero, the system switches to screen 5 and, via 
GPI, triggers device 104 to record and start the playlist sequence. Executable icons include: 

a) Hold - Holds the countdown sequence. 

b) Start - Re-starts the countdown sequence when Hold or Stop is triggered. 

c) Stop - Stops the countdown sequence and re-sets to the default countdown 

30 time. 
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d) Quit - Stops the countdown sequence and sends the user back to screen 3. 
Screen Five allows the user to see the playlist sequence while the user synchronizes 
voice with each product. Executable icons include: 

a) Stop - Stop halts the process and re-sets the playlist and device 104. 
5 b) Start - Simultaneously re-starts the playlist and device 104. 

c) Re-play - Allows the user to perform quality control on the presentation. 

d) Send - Sends the product and voice files to their proper holding destination 
before going up on the satellite. 

VOSS 77 functional requirements preferably (but need not) include: 
10 1 ) Voice files are mixed at receiving unit 1 4 during the local forecast with the 

national music feed. The national feed may be reduced by 2db (-30%) and the voice file 
played back at its normal level. 

2) A priority "one" playlist is transmitted within 5 minutes of iMDS 68 receiving 
the request. 

15 3 ) Each in-house receiving unit 14 is configured regionally. Receiving units 14 

are placed on the router and routable to any selected voice booth 102. 

4) All updates from product server 76 to all in-house receiving units 14 are 
automatic and continuous. 

5) Regular forecast air pass-through audio at their full levels. 

20 6) Playlist for all markets are pre-built products. The operator has the ability to 

dynamically edit playlist fields. This includes durations, products, expiration time, priority, 
and time slot. 

7) All playlist files are scheduled to transmit once received by host 52. If the 
associated audio file does not reach the receiving unit 14 when local forecast 16 is triggered, 

25 the system recognizes that the associated voice file is not present and passes national audio at 
its full level. 

8) The in-house receiving units 14 must be continuously updated with the most 
current data by product server 76. 

9) When host 52 transmits new weather data to the field, receiving unit 1 4 

30 associates that new data with current voice-supported products airing during local forecast 16. 
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Once the association is made, receiving unit 14 dismisses any voice file previously associated 
with that product(s) and go to national default audio. However, some products continuously 
receive updates during the life of a play list (e.g. temperature, wind, etc.) These products 
should continue to play their associated audio files. These products are identified for the 
5 programmer. 

10) Improperly formatted messages are rejected and passed to the receiving unit 
VOSS position. 

1 1) All specific playlist and voice support terminate at their expiration time. 

12) All narrative text updates are performed preferably at met system 66 terminal 
10 rather than VOSS 77. 

13) Each element of a playlist is recorded separately and reassembled at receiving 

unit 14. 

14) Each element of a playlist may be recorded individually or collectively. 

15) Ability to request supporting data, playlist, etc. from multiple VOSS 77 work 
15 stations. 

Local transmission 16 may also include video portions, such as local weather reports, 
commercial advertisements, etc., tailored to each region. To record the production of local 
weather reports, additional video recording studios 106 must be installed. Studios 106 can 
also act as backups for national transmission 60. Production systems facilitate the recording, 
20 storage, and transfer of digital media. 

Recordings from local video studios 106 are stored on media server 108 until 
transmitted to receiving units 14. Each local video studio has manual control panels, much 
like the national studio. These panels can also be used as a backup, should the main studio 
control panel fail. 

25 The primary source of information, which may be weather data or other types of 

information, enters the system through met system 66. Met system 66 is a system for 
collecting and formatting data for use by the other elements of system 9. Met system 66 
preferably communicates with host 52 via TCP/IP Ethernet. Met system 66 feeds all 
localized weather data — temperature, weather conditions, etc. Such data features an address- 

30 level scheme information for downward compatibility with previous systems. These 
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addresses are converted into the Command/Query architecture. Met 66 provides the national 
radar map, immediately upon receipt, as frequently as every five minutes. Host 52 is 
responsible for sending the map to all receiving units 14 within the next five minutes, but 
preferably on an average of no more than thirty seconds following receipt by host 52. 

Warnings and advisories are transferred in real-time and host 52 transmits them to 
receiving units 14 preferably within one minute and more preferably within thirty seconds. 
Warnings or advisories not sent because of the system's inability to interpret them should be 
displayed on the command console and/or printed. 

Media server 70 stores digital and audio clips for future transmission, and records and 
transmits data on command from automation system 72. Because of its transmission method, 
it can only store digital video and audio (Class C) files. Tape console 44 is currently 
envisioned as a component of the media server 70. Tape console 44 is a video tape 
"jukebox," such as an Odetics, and acts as a repository for video productions off-loaded from 
the media servers, particularly national commercials. 



Coordination and Assembly of Data 

To route data to individual receiving units 14, host 52 requires affiliate information. 
The Affiliate Information Management System (AIMS), maintains affiliate-related data for 
each receiving unit 14. Each receiving unit 14 is at an affiliate's place of business. That data 
is maintained by affiliate database 20. Because the goal of the system is to provide increasing 
localized productions, affiliate database 20 stores configuration modifications made to each 
receiving unit 14 from a generic configuration. Affiliate database 20 consolidates data into 
working files for addressing by host 52. When data is downloaded to a receiving unit 14 
during full reconfiguration, data remains on affiliate database 20 for dynamic access via 
25 TCP/IP. 

To access the required data, product server 76, AIMS and affiliate database 20 
requires connectivity capable of establishing links between foreign databases. With such a 
link in place, a read-only interface into affiliate database 20 provides access to its data 
elements. Data is then converted to a predetermined data format and posted to the product 
30 posting file 84, where host 52 can access the information. 
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Affiliate database 20 supports additional features, thus the database is preferably 
modified to contain the following additional fields: 

Receiving unit type . This field contains a value indicating whether receiving unit 14 
is a local edition or a standard receiving unit. 
5 Receiving unit IP Address . This field contains the IP address of receiving unit 14 to 

facilitate use of Command/Query. 

Host File . Affiliate database 20 compiles affiliate data into an addressing file for host 

52. 

Update host . Mass updates may occur once each day, such as at 1 8:00 hours (6:00 
10 PM) Eastern Standard Time (EST). 

S4_Address . Refreshes receiving unit data once each hour. 
Ski Tags . 
Rotate Ski Tags. 
G a rden Ta gs- 

15 

Master Dynamic Scheduler (MDS) 68 adjusts systems 9's schedule and communicates 
that schedule to automation system 72 and host 52. MDS 68 coordinates with all other 
system elements to update schedule adjustments. MDS 68 also calculates and schedules the 
downloading of products 64 from product server 76 through the host 52. MDS 68 may 

20 simply provide for original posting of and updates to the daily schedule log. MDS 68 may 

also organize and schedule product downloads through other channels outside host 52. MDS 
68 may also organize the routing of digital media, such as host command data, device 104 
audio data, and media server 108 digital video data, over available digital lines. 

Automation system 72 is a scheduling subsystem that controls and schedules the 

25 production components. Some schedule events such as off-line video and audio production, 
are in the domain of automation system 72. However, when scheduling affects the 
transmission of information to receiving unit 14, automation system 72 works as a sub- 
system of MDS 68. 

Host 52 accepts its schedule from MDS 68. To execute the next event in the schedule 
30 list, a Take Command is sent from automation system 72 in the form of a 5-volt pulse. When 
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such a command occurs host 5"> scndc n ,- n mm,„j ,„ . , . 

uii, nobi ;>„ senas a command to receiving unit 14. Host 52 acquires 

prioritized data from the product server 76: 

Priority 1 - Class A command data and important weather information. 

Priority 2 - Class B standard weather data. 

Priority 3 - Class B data consisting of programs and graphics. 

To execute the next event m the schedule list, a Take Command is sent from real-time 
source book 78 in the form of a 5-volt pulse. Host 52 takes the data and delivers the data to 
the master router 80 for delivery to receiving units 14. 

Host 52 also performs some additional formatting of the data. For instance, text may 
be formatted for particular screen configurations to avoid orphans or other aesthetic 
anomalies. Host 52 may also perform some dynamic scheduling. For instance, by applying a 
set of rules, the host may determine that a particular set of data is more time critical than 
other data and move the time critical data to a higher transmission priority. For example, a 
weather warning might override data reflecting current weather conditions. Thus, the weather 
warning information would be moved to the front of the queue. Backup host 74 also accepts 
its schedule from real-time source book 78. 

As illustrated m FIG. 9, product server 76 is the primary central database and 
computing resource for system 9. It is responsible for handling of addressing, configuration, 
meteorology, data mirroring, and transaction logging for host 52. Through Product 
Development Management System 84, all meteorological data, presentation products, and 
configuration information are docked for eventual transmission to a receiving unit 14. 

From the product server 76 perspective, there are three types of data that must be 
transmitted to receiving unit 14 to form a transmission: Command, Cyclical, and Real-Time 
Weather Data. As notices of modified data are received by product server 76, they are 
categorized accordingly. This categorized data is then formatted and combined with 
addressing information retrieved from affiliate database 20. This final data product is posted 
to Product Posting File 82, which is continuously polled by host 52. Product server 76 and 
host 52 may be resident on a single platform such as a Hewlett Packard 9000, or may be 
resident on separate platforms. 
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Referrine to FIG. 7, the Master Control (not illustrated) allows monitoring and human 
intervention into the system. 

^y^em Maintenance 

The Engineering Maintenance System (not shown) provides access to. and diagnostics 
utilities for host 52. Maintenance System 86 provides hardware and software to configure 
and maintain equipment, and provides local and remote < modem) diagnostics of individual 
receiving units 14. 



10 T remission nf Progra mming to Receiving UnilS 

Master Router 80 routes all production lines, and has four important input lines. 
1 National Feed Video 82 which carries national transmission 60. 

2. National Feed Audio One 82 which carries the audio associated with national transmission 



15 



60. 

3 National Feed Audio Two 82 which cames alternate audio, normally for music associated 

with the national transmission 60. 

4. National Feed Audio Three 82 which cames alternate audio, normally for 
foreien language associated with the national transmission 60. 

Under the control of automation system 72 and the Master Control Panel mot shown). 
20 master router 80 coordinates inputs with the various outputs. The inputs defined above are 
matched with their corresponding outputs as follows: 

1. National Feed Video (NFV) 88 

2. National Feed Audio One (NFA 1 ) 90 

3 . National Feed Audio Two (NF A2) 92 
25 4 National Feed Audio Three (NFA3) 94 

From this point, all outputs take different paths to their final combination into a 

satellite signal. 

The national feed must be scrambled along with its two most closely associated audio feeds. All 
three. NFV 88. NFA1 92. and NFA2 94. are combined and scrambled at the National Feed Scrambler 96. 
30 Once combtned. this information is fed into sub-carrier combxner 98. Sub-earner combmer 98 takes the 
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following inputs and combines them into one broadband output including the scrambled national feed, 
national audio feed three 94 and receiving unit command feed 100. 

Additional equipment may be added to the transmission systems to accommodate an 
increase in data flow. This equipment provides the following data lines: 
5 Two 3.5MB Digital Video Streams 1 10, 1 12. 

1 6 Audio Channels with 256KB per channel (not shown). 
In such an event, the signals may be encoded individually before being combined. 
Encoder 1 14 encodes national transmission 60. Encoder 1 16 encodes digital video one line. 
Encoder 1 18 encodes digital video two line. Multiplexor 120 distributes encoded data 
10 depending on need. Combiner 98 compiles encoder lines into one transmission. 

A modulator (not shown) accepts video as analog, audio as analog, and data as a 
digital feed, and will modulate them into a broadband signal transmitted via satellite to all 
receiving units 14. For the transmission, the signal is compressed, providing three video and 
associated audio channels, along with three additional audio channels. This compression 
1 5 method also supports three data channels with a 5 12KB transfer rate. 

The portions of system 9 installed at the cable operators' sites consist of many 
subsystems allowing communications from host 52, connections to auxiliary equipment, and 
diagnostics. Referring to FIG. 8, the broadband signal transmitted from system 9 is^fed into 
the integrated receiver and descrambler, where the National Video (NFV) 88 and associated 
20 audio (NFA1 90 & NFA2 92) are separated and descrambled. Both are then fed to receiving 
unit 14, along with the descrambled broadband signal 122 containing all of the video and 
audio bands. 

The Digital IRD (not shown) is added to the existing Analog IRD. This device 
receives the compressed feed and provide selected access to the new digital audio and video. 
25 The system uses an RS232 control line from system 9 to determine which of the two digital 
data feeds will provide Dl input. On the audio side, each channel provides eight audio 
streams; the control line allows system 9 to select which of these it will use. 
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Delivery of Programming to the Viewer 

The programming is received by the affiliate and delivered to receiving unit 14 where 
it is processed for delivery to the viewer. Receiving unit 14 is considered an industrial 
automation system. It is capable of operating in an environment that is much different than a 
5 residential installation. The hardware must have a certain degree of expandability. 

Thus, in an illustrative embodiment, receiving unit 14 is based on a motherboard 
supporting a RISC SC processor running at 180 megahertz, 64 megabytes memory, a power 
supply, two two gigabyte hard drives, a high speed RS-422 data port, three high speed RS- 
232 data ports, a GPI interface, a fast and wide SCSI interface and a video processing board. 

10 Other components may just as easily be used to serve these functions. Various ports are 

provided for external interface, including a 100/10 BaseT Ethernet port for TCP/IP access. In 
the illustrative embodiment, a Silicon Graphics workstation is used as the platform, which is 
available from Silicon Graphics, Incorporated at 2171 Landing Dr., Mountain View, CA 
94043-0837. Other platforms may be used as receiving units 14 as appropriate. 

1 5 Receiving unit 1 4 includes software which is a multimedia playback engine, such as 

Evolving Video Technology's Antero presentation software. Other commercially available or 
custom developed presentation software may be used as desired or appropriate. It provides 
the basic data format on which the data provided to receiving unit 14 is to be displayed. It 
also includes a play-list of video effects. A play-list is the sequence of how the data is 

20 projected onto the screen in the appropriate location. 

For instance, a typical local transmission may comprise a template in which current 
weather conditions are displayed. The template is essentially a graphical design or structure 
with certain areas denoted as fields for particular types of data. One data field might be a title 
box which in one region may state the words "current conditions," and in another region 

25 might display the words "present conditions/' The selection of words may be made by the 
affiliate and is programmed into the affiliate data base. Furthermore, other graphical special 
effects may be included such as the maimer in which the text appears on the screen and 
various other types of visual effects, such as cross fades, etc. 

Receiving unit 14 provides video production on command to cable operators. To 

30 perform this procedure, the system requires the following inputs and outputs: Broad Band In 
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122 which provides command data from the host 52; Analog Video 88 which provides 
National Video Feed 88 for national transmission 60; Audio Left 90 which provides input for 
Audio Left (NFA1 90) for national transmission 60; Audio Right 92 which provides music 
for the local transmission 16; Analog Video Out 124 which provides the video signal for the 
cable network whether local transmission 16 or national transmission 60 is passed-through; 
Analog Audio Out 126 which provides the audio signal for the cable network whether local 
audio or national audio is passed-through; Weather Sensors in 128 which provides the 
attachment for local weather sensors; and RS232-In 130 which may be used with a modem. 

The receiving unit software is responsible for the basic operation of receiving unit 14, 
maintaining its database and overall maintenance. The software supports a subset SQL- 
compatible command strategy. It interprets SQL statements, first to determine whether they 
meet the query specifications, and second to execute their commands. The software may 
interpret precompiled or ASCII text versions of the command set. 

The software may execute a prerecorded, downloaded list of presentation events in 
1 5 coordination with the third-party application software. It monitors the execution of these 
events, down to the frame-leveh and has the ability to skip forward events in the playlist if 
required. 

The software supports a TCP /IP terminal interface for configuration and diagnostics. 
The options provided include the following : 
20 Log-in: Provides secure access to the system resources. 

SQL Command Line: A command line at which the user enters receiving unit SQL 
statements. 

Set Transaction Log Parameters: Allows the system engineer to select the event that will 
be written to the log. 

25 Set Transaction Log Duration: Allows the system engineer to select the amount of time 
events will be held before they are deleted. 

Set Cloud-Net IP Address: Allows the system engineer to set the IP address of receiving 
unit 14. 

Set Internet Assigned IP Address: Allows the system engineer to manage the true IP 
30 address of receiving unit. 
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Reset All: Reset the system. 

Reset Software: Purge all software and reload. 

Print/Transfer Transaction Log: Print the transaction log to a local printer, or transfer it to 
the host hard disk. 
5 View System Log; View the transaction log. 

Clear System Log: Purge the error and transaction log. 

Clear Current Errors: Clear the current error status, which will clear the notification icon. 
Configure notification parameters: Configure notification methods such as dial-beeper, 
show notification icon error levels, and report to host error levels. 
10 Command Query Interface: Allows the user to enter command query line entries. 
Log-out: Log-out. 

The system software records the following events: 
Failed File Transfers. 
Failed Command Interpretations. 
15 Operating System Errors. 

Optional Events with User-Defined Duration: 
Any Selected Query /Command. 
Any Select Data Element Access. 
Actual Execution Time and Duration of Any Playlist. 
20 Actual Execution Time of Any System Function. 

Monitoring of Any Input/Output Device or Port. 
The command stream between host 52 and receiving unit 14 is a TCP/UDP/IP 
connection selection protocol. When in satellite transfer mode, the socket selected provides 
a UDP protocol with a loop-back that simulates TCP connection orientation. When a 
25 connection is established over a communications line supporting TCP/IP, the connection runs 
under true TCP/IP. Simulating TCP/IP over the connectionless satellite communication path 
provides the system with the ability to receive data over the RS232 or Ethernet connections 
with error reporting. This facilitates diagnostics and off-line downloading of commands and 
data without the need of special utilities. 
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Software loaded on receiving unit 14 has a hardware abstraction layer that 
intermittently performs the following tasks: disk defragmentation; system database mirroring- 
configurable local dial-up reporting of system errors; configurable dial-up reporting to a 
global system error log; configurable beeper notification of system errors; and configurable 
display of yellow and red blinking icons to indicate that system errors have occurred 
requiring local-system engineers to review error log, solve the problem, and clear the error. 

The system database contains all information needed for operation. It supports the 
insertion or deletion of data elements. Data elements allow sub-fields. Sub-fields are fully 
configurable and have the capacity to contain the following data types: zero terminated 
variable length string, byte, integer, double, variant, and float. Weather data contains 
information indicating the data is valid only for a limited amount of time. The time period 
and time-stamp of the data are maintained, and the time period is configurable. 

One important goal of system 9 is to provide powerful product development tools to 
developers and remove custom programming tasks required from support staff. All products 
contain a presentation editing system capable of saving presentations and all effects in a 
useable file format. The software provides a run-time engine controlled by the system 
software that executes the pre-developed presentation in real-time. 

The editor allows smooth interaction with a Graphical User Interface developed for 
piaylist editing. Features allow for launching the run-time engine with a current playlist for 
testing and drag-and-drop editing of data elements onto the editing canvas. 

The run-time engine allows full control and communication with the system software. 
This control is at the frame-level. The run-time engine is able to communicate errors and 
allow the system software to ascertain missed frames. 



/Feature^ >%; 




Crawl 


Display all lines m a text block as a single line that crawls from left to 
right across the screen. 


Ease In 


During the first 25 percent of effects duration, effect starts slowly and 
accelerates to full. 
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Feature ; 


Effect 


Ease Out 


During the last 25 percent of effects duration, effect decelerates to the 
effects completion state. 


Chroma 
Key 


Use oi a video signals color characteristics to cut a foreground image 
into a background image. 


Page Reveal 


Reveals the new page as the existing page pushes off of the canvas from 
the direction the user specifies. Effect direction: From bottom left, 
bottom right, left, right, top left, top, top right. 


Push 


Pushes a new page on to the canvas from the direction the user specifies 
while pushing the existing page off. Bottom left, bottom right, left, 
right, top left, top, top right. 


Reveal 


Display different objects on a page based on the order in which the user 
entered, until the entire page is displayed. Bottom left, bottom right, 
left, right, top left, top, top right. 


Reverse 
Crawl 


Display all the lines of text on the page as a single line that crawls from 
left to right across the screen. 


Reverse 
Roll 


Roll each line of the page vertically down from the top of the screen at a 
specified speed until the top line rolls off of the canvas. Effect 
direction: Top. 


Reverse Zip 


Move each line of text on the canvas from left to right based on the 
order in which the user typed the lines. All lines of text end up justified 
on the screen. Effect direction: Line by line from left. 


Roll. 


Roll each line of the page vertically up from the bottom at a specified 
speed until the bottom line rolls off the screen. Roll-effect direction: 
Bottom. 


Wipe 


Wipe a new page on screen and the existing page off from the direction 
the user specifies. Wipe-effect direction: Top down, bottom up, center 
out, right to left, left to right. 
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Feature 


Effect ■■" — — 


Zip On 


Move each Ime ot text on to the canvas trom right to left based on the 

order in which the user tvneri rhf» lin^c nrru * j 

me ubcr typea me lines. Effect direction: Line by line 

from right. 


Multi-line 
Crawl 


Simultaneously craw/ each line on a page in different locations on the 
screen. Crawl - effect direction: From left to right, right to left. 



Receiving unit 14 is aimed at providing highly sophisticated, visually stimulating 

presentations of information. 

Each receiving unit 14 has its own set of base maps and station identifiers. Base maps 
have projects information allowing for the proper placement of station (city) identifiers. A 
table showing a station's latitude, longitude, and name (long and short names) is stored in the 
database. (The latitudes and longitudes are visual latitudes and longitudes, not the actual.) 
Each receiving unit 14 may store the actual latitude and longitude of the cable operator, along 
with the visual latitude and longitude for the center of any local view ports. 

Receiving units 14 support a zooming capability. At various levels of the zoom, 
information, such as city names and weather conditions, may be hidden or revealed. A macro 
scale view allows the viewer to see less density of cities, while a tight zoom-in allows the 
more densely clustered cities to appear in an easily readable form. Also, receiving units 14 
support any map projection and are able to merge maps of differing projections. 

Receiving units 14 are capable of dynamically changing the products or the sequence 
of products within a product or "flavor," and creating a new flavor. Products are what the 
viewer sees. Local forecast, Regional Observations etc., are all presentations made up of 
different elements. Products or "flavors" consist of many types of data like template files for 
each page the viewer sees, sequence files that tell the pages when and how long to run, and 
product components like bitmaps, icons, and animation's that the pages use to build a 
presentation. The data that makes up products are product inventory items. Again these are 
the templates, sequences, and graphics that make up any presentation. These can be viewed 
as the tool chest the presentation engine uses to produce presentations. This is true for each 
individual receiving unit 14, as well as universally. The local forecast flavors are smart. This 
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allows event-actuated local forecast products. For example, if a particular receiving unit 14 
does not have radar echoes within its specified viewport, a different product can be presented. 

The logic in the programming language that wraps around the graphics rendering 
script allows receiving unit 14 to pick its product, generally depending on its interest list, for 
example, Tides versus Almanac. Locations along the coast would display tidal information, 
while in-land areas display the almanac. 

Graphic/video functionality is provided as follows: ability to change style, speed, 
location, fonts, timing, and type of a crawl; ability to support real-time compositing; ability to 
record and playback full-motion video in real-time; ability to insert live-local presentations 
either as pass-through or off the disk so that the presentation can be either full-screen or 
squeeze-zoomed to show additional weather information; ability to squeeze-zoom the 
national or local transmissions to show additional weather information; ability to double-box 
or pass-through video for two independent video sources; ability to digitize a video stream to 
disk; ability to adjust compression rates of incoming video stream; ability to transfer from the 
national transmission to the local transmission or information screen; ability to show motion 
video as a background, either in real-time or off the disk; ability to make city identifiers 
translucent to avoid covering them by such other items as radar information; and ability to 
composite (layer) images. 

The logical addressing of receiving units 14 is non-hierarchical and may be installed 
on the disk drive prior to shipment. Because changes may occur in the scheme, the 
addressing is down-loadable from host 52 and addressed by machine-readable serial number. 
Receiving units 14 can receive and store audio or video files. 

Bit-mapped graphic images, such as icons, radar data, and base maps, are received and 
stored in the JPEG compressed format. The quality (Q) factor of the image are maintained at 

80 percent, or better. 

For National Weather Service (NWS) text bulletin data, receiving unit 14 selects 
bulletins to be stored in the database based on the passing or failure of two filters: bulletin 
type and station list (Universal Generic Code or UGC) embedded in the WMO header (such 
as WFUS1 and GAZ032, respectively). 
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If a particular receiving unit 14 is interested in that bulletin type, i, then parses the 
station list embedded in the WMO header. If the station list parsed out of the message 
matches a station in the receiving units' 14 interest list, h is stored in selected receiving units' 
1 4 database. 

A quality control routine is performed for confirming time. If the bulletin has expired 
e.g., the expiration time stamp in the UGC is less than the current Zulu time, the quality 
control routine rejects (ignores) the message. 

Certain bulletins receive special processing. Spec.al N WS-defined delimiters cause 
certain blocks of information to be stored and displayed in one of the many effects 
enumerated earlier. For example, a NWS Zone Forecast may contain a header that warns the 
public of existing watches and warnings. A process parses the useful information, stores it. 
and creates a special display effect such as crawl, scroll, or other appropriate format. 
Properly delimited headlines used in NWS bulletins such as Nowcast, Short Term Forecasts, 
and 36-Hour Forecasts, are parsed out of the bulletins and stored as separate entities. 

Tabular data is alpha-numeric weather condition and forecast information. Each 
tabular data type, e.g., Regional Forecast, Hourly Observations, etc., is accepted and stored bv 
the receiving unit 1 4 based on the following: The message is a valid tabular data type, or a 
station in the interest list exists that matches the station field contained in the tabular record. 

All data types stored in a receiving unit 14 database are time stamped by the 
originating system. Time-stamps use the Universal Coordinated Time (UCT) or Zulu 
(GMT) format. All NWS tabular data types expire in the database after a specified time 
period. The Product Team is responsible for determining the life cycle for each data type. All 
NWS narrative data types are deleted upon expiration of the bulletin specified in the UGC 
time-stamp field. All local video and audio products recorded on receiving unit 1 4 have an 
expiration time-stamp. At the end of a product's defined life cycle, receiving unit 14 defaults 
to a local forecast flavor if the system does not detect an updated or new local specific 
product. 

Clock messages for host 52 cause receiving unit 14 to update the time. All clock 
messages are in UCT or GMT format. The clock remains on the screen in a given format 
despite the changing background. Receiving unit 14 supports configurable time formats 
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(both 12-hour and 24-hour). This feature allows the installation of receiving unit 14 
anywhere around the globe. The clock is used to generate a date and local time display, to 
confirm values on data received and to time-stamp locally acquired products, if any. The 
clock is capable (under software control) of interfacing directly with the video output for on- 
5 screen displays. Each receiving unit 14 maintains an offset-value in its database, allowing the 
calculation and display of local time on-screen. Receiving unit 14 supports update-cycles 
occurring as frequently as five-minute intervals. The update cycle is not hard coded, but 
configurable. 

Receiving units 14 support animation (appear as pass-through) of radar images stored 
10 in receiving units' 14 database. Receiving unit 14 displays images one frame at a time at a 

controllable and programmatical rate. Receiving unit 14 maintains a table of radar images for 
a specified number of hours. The number of radar images stored is configurable. After a 
given interval, each radar image is deleted. The table is in ascending order based on the time- 
stamp embedded in the radar image. 
15 Receiving unit 14 interrogates the radar information upon receipt for data that exceeds 

a given threshold. A flag indicating whether or not the value has been exceeded is stored in 
the system and accessible to the playlist interpreter. If the threshold is exceeded, receiving 
unit 14 generates a different playlist. Thus, a radar image showing a high density of high 
intensity returns may generate a severe weather warning. Because the quality of radar data is 
20 not controlled by its provider and the data may need to be adjusted depending on the seasons 
of the year, each receiving unit 14 has a mechanism to filter out specified radar levels (color 
levels). 

When a valid warning message for the area is received, receiving unit 1 4 creates a 
map, either as a bug or radar base map, that fills the affected counties with a specified color. 
25 When the warning expires, the map goes back to its normal, unfilled, state. Valid 

warning/advisory messages are stored and placed in a crawl for display. The colors of the 
font background may correspond to a given warning/advisory type. For example, warnings 
may be displayed in red, watches in yellow, snow/cold in blue. Receiving unit 14 generates 
an alert tone or plays a pre-recorded audio file for each warning/advisory type. Also, each 
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receiving unit 14 has information on warning/advisory types currently in effect, allowing it to 
change the local forecast product depending on the type of warning/advisory. 

Convective warnings (severe thunderstorm, tornado, and special marine) generate a 
short (abbreviated) form of the warning message based on the fields contained in the WMO 
header. For example: 

WFUS1 = Tornado Warning 

GAC0I3 = Cobb County, Georgia 
1 2 1 645 = Expiration date and time 

The resultant message would be as follows: "A tornado warning is in effect for Cobb County 
until 4:45 PM EDT. Stay tuned for details." 

Receiving unit 14 support four modes of operation. Normal, No- Video, No-Data, and 
Reset. Normal Mode is the typical operating mode of receiving unit 14. It is maintained 
until receiving unit 14 fails to receive a valid data packet for one minute, if the satellite video 
is lost for 45 consecutive video frames (defined as loss of genlock), or if data is received to 
15 force receiving unit 14 to another mode. In normal mode the control of receiving unit 14 
remains with the host. 

No-Video Mode is entered if receiving unit 14 fails to receive satellite video for 45 
consecutive frames. When the No-Video Mode is entered, receiving unit 14 is forced into a 
playlist designed by the product designer/programmer. No- Video Mode is canceled when 
20 satellite video is restored for the required period of time and data is present. In a receiving 
unit 14 equipped with telephone line access, the diagnostic routine contacts the production 
headquarters after detecting the No-Video condition for fifteen minutes. 

No-Data Mode is entered when a receiving unit 14 fails to receive clock or data for 
one minute and after a successful Reset. When No-Data is entered, receiving unit 14 is 
25 forced to call a run playlist designed by the product designer/programmer. No-Data reverts to 
either No- Video or Normal Mode when receiving unit 14 receives sixty consecutive error-free 
frames, and when a complete program is resident in memory. After 15 minutes of No-Data, a 
receiving unit 14 equipped with telephone line access contacts the transmission source. 

The Reset Mode is invoked in one of three ways: (1) A reset command from host 52 
30 in which a manual reset command results from pushing the Reset button on the Main CPU. 
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(2) Loss of AC and DC power where, if the start-up test procedure passes, receiving unit 14 
mode changes to No-Data. (3) If the start-up test fails, the sequence recycles. 

A downloading procedure is also provided. Normally, the most recent version of the 
system software is installed on the disk before delivery. However, it may be necessary 

5 occasionally to download new versions of the software. 

Message frames containing downloadable software, if correctly received at receiving 
unit 14 and identified as having a different version number from the current operating 
module, are stored on the disk. Frames incorrectly identified as having the current version 
number are rejected. New software is marked as "Unusable" until all frames are correctly 

10 received. Database objects (playlists, configuration, interest lists, addressing table, tabular 
weather data, narrative weather data, graphics, etc.) is buffered temporarily before 
committing them to database. The system checks to see if the object is in use (currently 
referenced). If the object is being used, it is marked as "locked/ 1 and waits in the buffer until 
the working version is marked as ^unlocked." When it becomes "unlocked," the object is 

1 5 deleted from the database and the new version is stored. Digitized video objects, not pass- 
through video, is stored on disk in either a compressed or uncompressed format. Version- 
control need not exist, but the object is not marked as complete until all frames have been 
received from the host. 

Receiving unit 14 supports a terminal interface (TTY). The interface allows 

20 receiving unit engineers and programmers to interrogate databases, perform self tests, change 
configuration items, check current version numbers of software, check physical serial number 
of devices, and override serial numbers. A transaction log is maintained for tags, weather 
warnings, and receipt of local forecasts. The log is accessible through the terminal interface 
and stored on disk. The log is purged at a programmable interval specified by the operator. 

25 If serious errors are occurring on receiving unit 14, it will, if accessible by modem, 

send a notification message back to the operator. Two passwords are maintained by the 
receiving unit database to use the interface. One is a "privileged" password for the operator 
allowing full access to all database elements. The second, a "non-privileged" password, is for 
affiliates permitting limited access to certain functions, such as crawl creation and scheduling. 
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The affiliates can change their password, which is initialized to a default setting at the time of 
installation. 

Using the interface specified above, affiliates are able to create a plurality of crawls. 
An edit function allows operators to create, update, and delete messages, and affiliates can 
also activate and schedule messages. The scheduler is designed to allow the cable operator 
to specify the frequency of the crawl rotation or indicate that the crawl is to rotate every other 
local forecast segment. The default setting specifies the crawl rotation frequency. Receiving 
unit 14 maintains a log of when a crawl was active. This feature assists affiliates in billing 
their clients. Local Ad Sales text messages are capable of effects other than crawl, such as 
fold, dissolve, and flip. The product developers decide what effects are used to display the 
message. 

Receiving units 14 are provided three software-controlled TTL contact closures. 
These closures can be used for inserting local commercial or weather warnings. The contact 
closures are on the Data Ingest Board. 



Operation of the System 

As illustrated in FIGS. 10 through 1 1H, the processes which operate throughout 
system 9 are broken into a number of modules, each having distinct tasks. In order lo 
facilitate complete modularity of design and facilitate the division of labor that accompanies 
20 such a design, system 9 incorporates the concept of a "software plug." Software plugs 1 32 A- 
n are based on Sockets, a UNIX O/S construct that has become popular with the growing 
influence of the TCP/IP based Internet. FIG. 12 illustrates the socket classes of system 9. 

In order to provide module interchangeability and ease of use, software plugs \32A-n 
are provided in between each of the modules. Software plugs 132A-* provide connectivity 
25 and safe transport of data from one process space to another regardless of whether that 

process space resides on the same machine or another. In order to perform this function, the 
data proceeds down through three layers of the source socket and up again through the 
destination socket. Referring to FIG. 13, a software plug 132 has three layers: packet type 
134, packetizer 136, and socket 138. The process flows as follows: The application fills 
30 packet type 1 34 with the appropriate data. The data is then serialized at packetizer 1 36, 
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meaning that the data elements are strung together into a stream. Once streamed the data is 
framed into 5 1 2 Byte segments, assigned a message number and segment number and 
transferred to socket 138 for transmission. Once transmitted the process is the opposite at the 
receiving side. Socket 138A receives the frame which is passed to packetizer 136A where it 
5 is reassembled. Once assembled the stream is deserialized and the elements are again 
populated into structure 134A for use by the application. 

Software plugs I32A-/7 allow for standardization of objects and allow the programmer 
to select the communication system used based on line quality. In other words, sockets 138. 
1 38 A may or may not include error checking, depending on the connection type that is used. 
10 For instance, if two modules are resident on the same hardware platform, sockets 138, 138 A 
may not employ error checking because line quality is assumed to be good. On the other 
hand, where the modules are located on two separate platforms and the potential for line 
degradation exists, error checking may be introduced at a level corresponding to the difficulty 
anticipated with the line quality. 
15 Data in system 9 are stored in a structure or packet type. As illustrated in FIG. 14, 

three structures are defined for system 9: 

The Universal Product Posting Structure . This structure contains the data and 
addressing information required to package data from external sources for use with 
system 9. 

20 The Command Structure . This structure contains the blocks of data that make up files 

transferred to receiving unit 14 via virtual channels. 

The STAR Structure . This structure contains the format for data as it is moved 
between modules making up receiving unit 14. 

Each module in system 9 is based on a common module. This module called 
25 "appclass" contains all behavior common to the modules. The common functionalities are: 

Signal Handling 

Error/Even Handling 

Configuration Files 

Basic Module Format 
30 Console Communications 
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System 9 is designed to be immune to underlying data bases. FIG. 1 5 defines the data 
base abstraction classes for system 9. The following file records are used in system 9: 
Receiving Unit 14 Dynamic Information File Record (See FIGS. 16-16A). 
Receiving Unit 14 Mirror File Record 
5 Receiving Unit 14 ID File Record 

De-Queue Accumulation File Record 

Each module in system 9 contains a configuration record. There is only one 
configuration data base and one record for that data base, although the fields of the record are 
redefined for each module. The following tables illustrate the configuration records used in 
1 0 system 9: 

US Met Tabular Ingest Configuration Record 



1 Element Name ; 


Type 


Description 


Wind Chill 


char 


Wind Chill ^^^^^^ m 


Moon Phase 1 


int 


Index phrase / icon list 


Sea Condition 


int 


Phrase list index 



Product Posing Module Configuration Record 



Hlement Name*- 


Type 


Description 


IngestPort 


int 


Port Number for Ingest Server Port. 


RequesterPort 


int 


Port Number for Requester Server Port 
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Host Request Module Configuration Record 



Element Name 


Km 


Description 


ProductPostingClientPort 


int 


Port Number for the product Posting Port. 


QueueClientPort 


int 


Port Number for Queue Server Port. 


Queue Server Module Configuration Record 


J lilement Name 


Type 


Description 


RequesterServerPort 


int 


Port Number for the Host Requester 


CommandServerPort 


int 


Port Number for Command. 


Priori tyQueue 


int 


Number of priority queues for this 
implementation 



Command Module Configuration Record 

>* 

10 



Element Name 




mm 


Description 


QueueClientPort 


int 


Port Number for the Queue Server 


ComandServerPort 


int 


Port Number for DeQueue 


De-Queue Module Configuration Record 


1 {lenient Name 


Type 


Description 


RequesterServerPort 


int 


Port Number for the product Posting Port. 


CommandServerPort 


int 


Port Number for Queue Server Port. 



15 
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CAM Module Configuration Record 



Element Name 



RequesterServerPort 



CommandServerPort 



int 



int 



int 



Description 



Port Number for the product Posting Port. 



Port Number for Queue Server Port. 



20 



25 



Product Server anrf Hosr As shown in FIGS. I 1 through 1 IB, data is received by 
product server 76. The data flow begins at the ingesters 140. The entry point into system 9 
ingester 140. Ingesters 140 provide an interface to the outside world for posting products of 
all types, converting them from their raw format into a Universal Product Posting Structure. 
FIG. 1 8 illustrates the flow of information through ingesters 140. 

Ingesters 140 acquire the data and construct a data packet in a predetermined formats, 
such as the Product Development Management System (PDMS) format. The PDMS packet 
includes the data itself and other information about the data such as the address, the data 
length, the address length, the systems to which the information is to be posted, the priority of 
the data and the expiration date of the data. 

The PDMS packets are then forwarded to product posting module 142. Here the data 
is held in various lists, each list being dedicated to one or more modules which acquire the 
data, such as host 52, an Internet device, or other systems 1 92 that might be interested in the 
data. 

As illustrated in FIGS. 1 IB and 19, product posting module 142 provides input into a 
dedicated queue from multiple sources of product data. For example US, meteorological data 
can originate in tabular 1 70, narrative 1 72, or map 1 74 file form. Each ingester 1 40 must 
package the product into a Universal Product Posting Structure and then must post that data 
to a single product posting queue 1 84 which is dedicated to a data requester, such as host 1 46, 
internet 1 92, etc. 



is 
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The product posting process starts at the source of data, such as tabular 170, narrative 
172, and maps 174. Assigned to each ingester 140 is an ingest task 176 within product 
posting module 142. Both ingest processes and ingest tasks 176 have configuration 
information indicating their Port ID's. Ingest tasks 176 have a client 178 to server 180 
5 relationship with the ingest processes through software plugs 1 32A-B. A server socket 

simply means the UNIX port is owned and managed by the module and that multiple clients 
can attach to that port. The module connecting to the port is termed the client. 

Ingest task 176 accepts data packaged as PDMS construct. The PDMS structure is 
defined in the table below. 



Element Name 


Type 


Description | 


Source 


int 


Indicates the target queue number. 


Priority 


int 


Indicates the priority. 


Address 


char* 


rvCdjJIGIll O 1 /Arv auuicia. 


AddressLength 


int 


Length of address data plus terminating NULL 


Data 


unsigned 
char* 


Product data 


DataLength 


int 


Length of data 


ERStoreFlag 


int 


Indicates whether data is internally stored 

(T ISTORE) stored externally from the packet 

(TJESTORE) or stored remotely (TJtSTORE) 


ERStoreLength 


double 


Length of externally or remotely stored data 


EffectFlag 


int 


Data size has an effect of the total hard disk 
capacity of the receiving STAR, 
EFFECTNOSIZE, EFFECT_SIZE 


MessageNumber 


long 


Message Number 


MessageExpiration 


long 


Time at which the message expires. 


CompressionFlag 


int 


Can data be compressed 


Segment ID 


long 


Segment for E_STORE transfers 



48 



BNSDOCID: <WO 9815122A1_I_> 



WO 98/15122 



PCT/US97/17412 



10 



15 



Source indicates the queue to which the product will be posted. The priority flag 
indicates the priority of the packet. These packets eventually are posted to a priority queue 
Address contains the full select statement and addresses of receiving units 14 to which the 
data is targeted. Address ,ength is the length of the address data. Data contains the data of 
the product. Th,s can be one of two things, actual data or a pointer to remote or external data. 

After blocking on a semaphore 182 for shared memory access, the packet is posted to 
queue 184. Ingester task 176 must accumulate the total data posted to queue 184 in order to 
track the total data in queue 1 84 at any one time. 

Before the packet and its data can be posted to queue 1 84, ingester task I 76 must do a 
look up in mirror file 154 and calculate the amount of space required by the data. Some data 
on receiving unit 1 4 is pre-allocated and therefore has no effect on the overall d.sk space. In 
this case the Effect flag is set to EFFECTNOSIZE. If the size of the data must be calculated 
the flag is set to EFFECT SIZE. If the calculation is made and does indicate the data does 
not fit on receiving unit 14 an error message must be posted and the packet thrown away. 

Queue I 84 is a Standard Template Library Multimap class. This class was chosen for 
the following reasons: 

It allows Key and Data both to be stored. 
It allows ordered insertions without sorting 
20 h allows ordered deletions without sorting 

Once packets are posted, the higher priority packets "float" to the top of queue 184 since the 
multi-map is keyed to priority. 

The architecture on the requester side is very similar. Product posting requester task 
1 86 is assigned to host requester process 1 46. They are connected by software plug 1 32D 
where product posting module 142 acts as a server and host module 146 acts as a client. As 
shown in FIGS. 1 1 B-C, the differences are two fold. First, host module 1 46 sends a ready 
message when it is ready for the product posting requester task 186 to forward the first packet 
off the queue. Second, only one product posting requester task 186 runs per queue 190, 
unlike the Ingester Tasks 176 in which multiple tasks can post to one queue 184. 



25 
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Product posting requester task 1 86 also has the responsibility of posting a record to 
mirror file 154. After the packet is transmitted to host module 146 it is then written to mirror 
file 1 54. The elements required for mirror file 1 54 are specified in FIGS. 1 6- 1 6A. 

Product posting module 142 accommodates three types of data: Internally Stored 
5 (l_STORE), Externally Stored (E__STORE) ? and Remotely Stored (R STORE). Because 

there is the potential for very large amounts of data, one of the pieces of information included 
in the PDMS packet is the l_STORE/E__STORE indicator. If the data packet is relatively 
small the data is labeled ISTORE, where the I signifies that the data portion is actually the 
data that is to be sent on to host 52 and eventually receiving unit 14. If the data packet is very 
10 large, it is labeled E_STORE and stored on an external server. The E indicates that the data 
packet is merely a pointer which indicates where the data may be found. Internally stored 
data, or I_STORE data, is transferred via a single packet. Since I_STORE data is limited to 
2- kBytes it can be sent in one packet. 

When external data, or ESTORE data, is sent the process is different. First the 
15 PDMS packet entry is sent to product posting module 142 as it would be for any I_STORE 
entry except for the fact that the E STORE flag is set to E_STORE, the file name is 
contained in the data element and the E_STORJE Length is set to E_STORE, the file name is 
contained in the data element and the ESTORE Length is set to the length of the file. After 
receiving the packet the product posting module 142 evaluates the E_STORE flag for the 
20 value E_STORE. If this flag is true then ingest task 176 expects the file to follow in 2048 
byte segments. 

The file is posted by absolute file name in a directory name based on queue 1 82. The 
naming convention is: 

[Current Directory] /queue [Queue Number] / [File Name] 

25 

For example, a file named 091502.96t. for queue 182 one be written to: 
. /queuel/0 91502 . 96 t . 
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Internally stored data is contained within the Universal Product Posting Structure 
Th,s ,s usually free from text data of the si 2e that can be accommodated by the structure " 
Usually text data shou.d be .imited to a configurable amount to insure that no single record 
eats excessive memory before it is cached to disk. Currently the system restricts internally 
stored data to I 0,000. 

Exception handling - in the event that the queues contain too much data for the system 
to handle, the product posting requester task 186 purges all non-prioritv 1 data from the 
queue. The determination of how much data is too much is configurable, but when this 
threshold is met all data excepting priority 1 data is purged from the file Currently 20 
KBytes is the maximum I_STORE data length. If a port is lost, all ports should drop into a 1 0 
second loop looking for connectivity when a port is dropped. Any port drops should be 
reported to the error log. 

Product posting module .42 provides more than just a universal conversion of data It 
provides a standard staging area for all commands and data that must be transported through 
system 9 to receiving unit 14 or from one machine to another. The reason for this ,s that a 
product may contain many sub-products, all of which must be moved around i„ system 9 in 
varying degrees and transported over different communication lines. Many products mav not 
even need to be produced before being transported. Product posting module 142 provides a 
central repository or central control area for items to be manipulated on their way to their 
20 final destination. 

Host module 146 picks up the PDMS packet from the product posting module 1*> 
and breaks it into two packets. The first packet is the address and the second packet is the 
data. This system allows receiving unit 14 to operate more efficiently. When the information 
gets to receiving unit 14 only the first packet is read. If the address indicates that the data is 
for that receiving unit, it then proceeds to store that data that follows the address. If the 
address is not directed to that receiving unit, it ignores all data until the next address packet 
arrives. This is important because it saves time that would be required for the receiving unit 
to parse through data. In order words, the receiving unit has only to parse, unpack or 
decompress the address packet to determine whether the data is directed at it. It does not 
need to decompress or reassemble any of the data, which may be time consuming. 
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As illustrated in FIGS. 1 1C and 20, host requester module 146 requests data from the 
product posting module 142 and processes into command packets to be transferred to queue 
server 148 to be staged for transmission. 

Upon start up, host requester 146 opens its configured port for access to an assigned 
5 product posting queue 184. This relationship is over a software plug 132D with the product 
posting module 142 acting as a server and the host requester 146 acting as client. The system 
allows multiple requesters to be attached to product posting module 142, but each requester is 
married to one product posting queue 1 84. 

Host requester 146 receives a new message for processing. Processing in this case 
10 means compressing the data of the message, if necessary, and breaking the message into 
chunks of command data. 

Requester task 194 requests data from its assigned queue 184 in product posting 
module 142 which is fed to it via a PDMS structure. Requester task 194 uses two work areas 
in memory so that one can be loaded while the other is unloaded. First the requester task 
15 checks an l A/B' flag 196 to determine which queue 190 is open and then begins to chunk 
data and load it into that queue 190. 

In order to understand the chunking process, the anatomy of a command message is 
illustrated in FIG. 1 ID. Generally any message is broken into four layers - command layer 
1 98, address layer 200, data layer 202, and optional file layer 204. Any message always 
20 contain address 200 and data 202 layer. Additionally if a file download is being executed it 
can be appended to the bottom. First, command layer 198 is written and the LayerFlag 
element is set to 0. Then the address 200 is broken into chunks of 512 bytes incrementing the 
segment number and setting the LayerFlag to 1 to indicate the address layer. Next the data is 
evaluated for length. If it exceeds 5 k Bytes, it first compresses the chunked into 512 Byte 
25 segments. Again the segment number is incremented appropriately and the LayerFlag is set 
to 2. If a file transfer is called for the host requester 146 sends a "RF" message loaded in the 
Data element of the PDMS structure. The table below defines the structure of the command 
data packets. 
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lilemenl Name 



MessageNumber 



ascription 



Data/Message Length 



long 



LayerFlag 



Segment Number 



Data 



long 



BYTE 



long 



void 




Length of data/Total number of segments in 
the message if LayerFiag=o. 



0=Command Layer 
1 =Address Layer 
2=Data Layer 
3=File Layer 



The number of this 512 Byte segment 



Data of the message 



int* 



Massage Priority 



server 



Once complete the Requester Service task sets the A/B flag to B and signals the queue 
task 206 that data is ready on queue 190. Queue server task 206 transfers the message chunk 
by chunk to the queue server module 148 which in turn populates it into a queue based on 

priority. 

Once the PDMS packet is properly formatted, it is forwarded to the queue server 148 
which has several queues, one for each class of data. Queue server 148 acts as a priority 
based stagmg ground for processed data ready for transmission to receiving units 14. FIG. 
I IE illustrates the function of queue server 148. 

Host module 1 46 establishes a client relationship via software plug 1 32E with queue 
server 148 where host requester service 208 thread requests pre-processed data chunks from 
host requester 146. Host module 146 provides messages as a series of command packets 
which are loaded into a queue. 

There are three types of queues: Y-queue 1 56, C-queue 1 60, and one or more priority 
queues 158. C-queue 160 is the command queue. Messages in C-queue 160 go out 
immediately after reception. The priority number of C-queue 160 is one. Y-queue 156 is the 
cyclical queue. Y-queue contains 1 56 the lowest priority data but the most critical data where 
iossiness is concerned. Files whose integrity must be guaranteed are placed in Y-queue 156 
in order to be transmitted a number of times thus insuring error free transfer. Y-Queue 156 
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priority number is two hundred and fifty six. Priority queues 158 accept a configurable 
number of priority messages. When configuring the system, the number of priority queues 
1 58 can be specified. The number of priority queues 1 58 specified is for error checking only, 
since any message entering queue server 148 that has an unallocated priority queue will, after 

5 checking the number of queues, automatically have one allocated for it. Command module 
150 provides the transmission of commands and data. This is its only function since this 
function is so important and susceptible to delay. 

As illustrated in FIGS. 1 IE and 21, command module 150 requests data from queue 
server 148 and transmits that data to De-Queue module 163 at receiving unit 14. Queue 

10 server 148 feeds data to command based on a strict algorithm that insists that high priority 
data be cleared from queues 156, 158, 160 as a soon as possible. As discussed in previous 
sections, commands can be sent through the system originating at any ingester 176. The 
problem that arises is the delays imposed by processing. Some commands require close 
coordination between broadcast production where delays of a less than a second are 

15 unacceptable. Therefore the command task 216 is assigned a schedule log 152 so that real 
time commands can be sent in the quickest and most efficient manner possible. 

Schedule log 152 accepts commands from the automation system 72. These 
commands are be executed at a particular time by impulse from a binary switch, also 
originating from the automation system 72. Command task 216 attempts to anticipate the 

20 next command and insures that it has time to clear the passageway to de-queue module 163. 
Command module 150 sends commands from schedule log 152 and data from product 
posting module 142 to receiving unit 14 whose address it gets from the High Speed 
Addressing File. Command module 150 periodically runs through queues 156, 158, 160 and 
selects the data according to a set of rules. 

25 Product data comes in three forms based on priority. The first source of product data 

is weather warnings and command data that must go out to receiving unit 14 immediately - 
this is C-queue 160 data. The second form of data is standard Meteorological Data which, 
although perishable, can get to receiving unit 14 in a reasonable amount of time after C-queue 
160 data have been sent. This is priority queue 158 data. The final form of data that must get 

30 to receiving unit 14 is programs, products, and configuration information, i.e., Y-queue 156 
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data. Cyclical data is sent over and over again in predetermined cycles to insure that it gets to 

receiving unit 14 in error- free form. 

Host module 146 increments through the product posting module 142 on product 
server 76 looking for priority queue and Y-queue data. If these types of products are found 
• and they are in excess of 4096 bytes then they are compressed. The compressed product is 
broken into transfer packets of 5 1 2 KB with a 64-bit CRC appended. Each transfer packet is 
then written to the appropriate queue priority data is written to priority queue 1 58 and cyclical 
data is written to Y-queue 156. 

An exception is made for C-queue data. If this type of data is written to the product 
posting module 142. a trigger is called that interrupts host module 146 and passes it a 
physical record address. Host 52 records its current increment and goes directly to the record 
in question and posts it to C-queue 160. Once posted, the host module 146 continues at the 

previous increment. 

An example of C-queue data is priority command data, i.e., data that must be sent to 
receiving unit 14 in real-time. Real-item command data originates in MDS 68 and is written 
to the Schedule Log 152. Also, any changes to log 152 are posted to host 52 from MDS 68. 
Schedule log is a queue with a pointer to the current command. An additional General 
Purposes interface (+5,0 volts) originating at automation system 72 goes high in order to 

signal host 52 to increment its command pointer and to send the command located there. 
Command module 150 responds immediately to the signaling of real-time priority 

data by the movement of the schedule command pointer. Command module 1 50 checks the 

priority command queue 1 60 for information. If there is information there, it sends it until 

queue 1 60 is empty. 

When the priority command queue 160 is empty and schedule log 150 is not 
incremented, command module 150 checks priority queue 158. If there is information there it 
sends a packet, then checks for new priority command data. If no priority command data 
exists and no schedule interrupt is received, then command module 1 50 sends the next packet. 
It essentially sends a packet of data and checks important priorities, if no important priorities 
exist it sends another. Finally, the monitoring of cyclic queue 1 58 works essentially the same 
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as with priority queue 158 except that if any priorities exist above it they are completely 
serviced before any cyclical packets are sent. 

Command module 150 also looks to schedule log 152 of MDS 68 and, if it notes that 
an event is coming which will consume transmission bandwidth, it may decide to hold the 
5 transmission until impending events are over. 

There is also a receiving unit mirror file 154 located on the product posting module 
142. This file records everything that is sent out to each individual receiving unit 14. It then 
creates a log of everything.that is resident on the receiving unit 14. This is necessary because 
the transmission system is an open loop which does not allow the system to know whether the 
10 data transmitted was ever actual received by the receiving unit 14. Thus, receiving unit 

mirror file 154 allows the system to know how full the hard drive of the receiving unit 14 is 
and if necessary send, delete or erase commands to eliminate stale data so that new data may 
be transmitted. 

The Receiving Unit; As illustrated in FIGS. 1 1G-H and 22-26, receiving unit 14 has 

15 four modules - de-queue module 163, command application module (CAM) 162, presentation 
application layer (PAL) 164 and hardware abstraction layer (HAL) 166. 

As illustrated in FIG. 1 1G, de-queue module 163 is the entry point for the system into 
receiving unit 14. It deals with receiving, interpreting, assembling, and transferring packets 
from and to command module 150 and CAM 162. 

20 Data messages are broken into command packets and stored in queue server 148^ 

Packets are stored in a single message made up of two sections. The front section is the 
address section and the back section is the data section. Each section is broken up further into 
frames of 512 bytes. Since command module 1 52 can remove packets with different message 
numbers from the queue 148 it is possible for the packets to be interleaved. De-queue 

25 module 163 therefore performs two tasks - first it resolves addresses for receiving unit 14 and 
then reassembles packets into messages if they are targeted a the particular receiving unit 14. 

Command module 150 opens a client relationship through a software plug 132G with 
de-queue server 163. The message top is reassembled in a disk queue and evaluated for true 
by look up in the Interest List section of Dynamic Information File 220. If the message is 

30 intended for the particular receiving unit 14 then de-queue module 163 continues to build the 
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message from the incoming packets. If the message is not intended for the particular 
receiving unit 1 4, then any received packets are discarded. 

When messages are complete they are transferred to CAM 162 through software plug 
1 32H after being converted to a data packet, as illustrated in the table below. The 
relationship between CAM 162 and de-queue 163 is one of "Priority Request." First, CAM 
1 62 indicates to de-queue module 1 63 when it is ready to receive any message by 
transmitting a ready string. This ready string can be of two types. The first is "RA" which 
means 'ready for all messages ' This indicates that CAM 162 is not extremely busy with 
other tasks. The other possible flag is an "RC" which indicates that CAM 162 can only 
receive command messages. This flag indicates that receiving unit 14 is probably m 
broadcast production and cannot be disturbed except for the most important information. 



15 



20 



Element Name 


Type 


Description 




i arget - HAL 


char*32 


Indicates the target HAL for the Message. 


Data 


void* 


Data of the message. 




Data Length 


long 


Length of data. 





25 



De-queue module 162 accepts messages from command module 150 based on the top of the 
message which is addressing information. Addresses are evaluated in the following format: 
SELECT [ALL,*] [WHERE [FieldName] [ = ,=>,< = ,.=] 
[FieldValue 1] [OR, AND] [FieldValue ..n]] 
The above expression simply states that the address is to select all (alternatively*) receiving 
units 1 4 that meet the certain qualifications. The SELECT ALL statement by itself has the 
effect of broadcasting to all receiving units 14 in the field. For example 
SELECT * 

and 

SELECT ALL 

would have the effect of passing the message to all receiving units 14 in the field since it 
would be evaluated as true. 
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The SELECT statement can be modified by the WHERE token to indicate that the 
whole statement needs to be evaluated for TRUE. The queue evaluates a FieldName for a 
some operation of a FieldValue. This means that the FieldName can be evaluated as being 
equal to, less than, more than, or not equal to, a particular value. For example, 
5 SELECT + WHERE MOUNTAIN_COUNTRY = 1 

would pass in receiving units that had the Field Name MOUNTAIN_CO(JNTRY set to a 
value of 1. Alternatively 

SELECT * WHERE MOUNTAIN__COUNTRY != 1 
would pass in all receiving units 14 not containing the Field Name MOUNTAIN_COUNTRY 
10 set to a value of 1 . SELECT parameters can be compound also. 

As illustrated in FIG. 1 IH, CAM 162 provides data base updates and communications 
routing services for the many modules running in front and behind it. All communications 
traffic is routed through CAM 162. 

CAM 162 accepts data and command concurrently from two sources: the standard 
15 satellite command feed from command module 150 and the service terminal 86. Each of the 
data feeds must interface with a separate de-queue module 163 married to the port of entry. 
Both attach to CAM 162 via software plugs 132H-L 

After filtering messages not intended for receiving unit 14, de-queue converts the 
command data packet into a receiving unit data packet and forwards it to CAM 162. 
20 CAM 162 responds to a limited number of commands. One set of commands tells 

CAM 162 to send the data to presentation application layer (PAL) 164. The second set of 
commands tells CAM 162 to send the information to hardware abstraction layer (HAL) 166. 
PAL 164 is a interface between CAM 162 and presentation engine 168. This allows 
presentation engine 168 to be replaced easily. 
25 HAL 166 consists of multiple layers which are small modules that can be written and 

run from CAM 162, including such desirable utilities as defragmentation routines, debugging 
routines, etc. By using many layers, each utility or function is a small piece of software. This 
allows new software to be easily downloaded to receiving unit 14 over the transmission 
signal. 
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CAM 162 contains application modules that provide most of the external activity of 
receiving unit. Commands enter the system in the SQL Command Query language subset. 

Configuration and weather data entering the system is written to the Dynamic 
Inventory File (DIP) 220, illustrated in FIG. 27. Also as the information in this file is need 
for other processes, chiefly the presentation software, this layer provides access to the DIF 
220 records. It is from CAM 162 that the third party presentation layer is called, executed, 
and monitored. 

HAL 1 66 contains kernel modules that service and monitor the system at the lowest 
level. The following modules make up this layer: 

P i .sk Marwmrnt Due to the heavy disk usage in multimedia applications and to the 
fact that receiving unit 14 is an automated system the hard disks must be constantly 
monitored and serviced. Th,s module monitors for disk problems in low periods and de- 
fragments in off times. 

Diagnostics , , Very low level diagnostics must be performed periodically and during 
certain events, such as the completion of a presentation to ensure that memory leaks have not 
occurred. This module performs diagnostics in an automated fashion or can be called by the 
Service Daemon for remote debugging. 

The Dynamic Inventory , All information involved in the system is reduced to a 
dynamic inventory. The configuration of DIF 220 is a flat indexed database which consists of 
two fields - Field Identifier and the Field Value. The relationship between receiving unit 14 
and product server 76 is shown in FIG. 16-16A. 

The Field ID and Data are meaningful depending on the context of the data. FIG. 29 
illustrates the data types used by system 9. If the data is program data, the Field ID represent 
a running program. If the data is weather data, the Field ID represents display data. This 
strategy provides an extremely simple design where the DIF 220 requires only three fields per 
record. This file allows the entry of new data types facilitating the expansion of product and 
weather data that can be presented and the number of effects that can be displayed. The 
format of DIF 220 is illustrated in FIG. 27. 

The parent record contains four fields as listed in FIG. 28 and the child contains one 
field listed in FIG. 28, as well. The above design accommodates variable length data by 
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breaking the data into segments. This approach has a further advantage in that DIF 220 can 
be pre-allocated on the receiving unit 14 hard disk 

Other modules may be included in HAL 166 as appropriate or necessary for the 
operation of receiving unit 14. 
5 Each receiving unit contains elements of configuration data. This data mostly tells 

receiving unit 14 who it is, where it is, and how its hardware and software should be 
configured. Data is transmitted to all receiving units 14 during any command transmission. 
In order to direct specific data to a receiving unit 14 the address must be contained in the 
message. If the receiving unit ''sees" its address in the message packet, it "knows 1 ' that the 
10 message is directed to it. 

DIF 220 keeps track of local conditions, forecasts, and notifications. This information 
is combined with the effects to produce the local weather products. DIF 220 keeps a list of 
utilities that are HAL 166-compatible. A record of where the program is located is required 
to execute these programs remotely. 
15 Receiving unit 14 must ingest all of the data being transmitted by host 52. First the 

incoming packets must be disassembled then the address header is resolved by a lookup in the 
DIF interest list to determine whether the message is intended for the specific receiving unit 
14. This activity takes place at CAM 162. If CAM 162 determines that the message is 
intended for it, it then determines what type of data it is being sent by evaluating the SQL 
20 command. There are only three possible commands - one to set data values, one to execute a 
HAL/PAL command, and one to execute a CAM command - just as in any SQL language. 

The format for setting a value is as follows assuming there is a DIF element named 

CURRENT_TEMP 

CURRENT_TEMP = 70 

25 CAM 162 determines that the message is intended to set a value in the DIF file. CAM 

162 first looks for the DIF FID. If the DIF FID is not present it then adds it and sets the 
value. If the DIF FID is present it simply replaces the current value. 
The format for executing any command is as follows. 

CALL ADO 1 
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Assuming that ADO I is a product (say current observations). CAM 162 looks up 
AD01 in the DIF file with the understanding that since it was preceded by a CALL statement 
that either a command is sent to the HAL 166 or PAL 164. Once found, CAM 162 evaluates 
the data type. If the data type is a program the command is sent to HAL 166. If the data type 
is product then the command is sent to PAL. 

Some commands CAM 162 recognizes immediately. Those commands are listed in 
FIG. 30. Commands set to HAL 166 are intended to executed custom modules. These 
modules are developed on top of a common platform so that they can report information back- 
to CAM 162 via software plug 132. 

Commands sent to PAL 1 64 are intended to either CAM 162, a product or to execute 
one of the limited commands PAL 164 understands. Commands PAL 164 understands are 
shown in FIG. 3 1 . PAL 164 executes products by passing the command to the Presentation 
Engine 168. Any monitoring information that must be passed back to CAM 162 is sent via 
queue-socket 132. 

1 5 Although the foregoing is provided for purposes of illustrating, explaining and 

describing embodiments of the present invention, modifications and adaptations to these 
embodiments will be apparent to those skilled in the art and may be made without departing 
from the scope or spirit of the invention. 



10 



61 



BNSDOCID: <WO 98151 22A1 J_> 



WO 98/15122 



PCT/US97/17412 



What is claimed is: 

1 L A method for distributing weather related video programming to each of a plurality of 

2 geographically disparate locales comprising the steps of: 

3 a) collecting meteorological data from each of the locales; 

4 b) transferring the meteorological data to a central processing facility; 

5 c) formatting the meteorological data to create programming products; 

6 d) transmitting the products via a transmission channel to information 

7 distribution centers in each of the locales; 

8 e) dynamically scheduling the transmissions to optimize utilization of the 

9 channel; and 

10 f) selectively displaying, via the information distribution centers and in 

1 1 accordance with geographic criteria, the products to provide weather-related 

12 video programming specific to each of the locales. 

1 2. The method of claim 1 further comprising the steps of: 

2 a) providing non-meteorological programming products; 

3 b) transmitting the non-meteorological products via a transmission channel to 

4 information distribution centers in each of the locales; 

5 c) dynamically scheduling the transmissions to optimize utilization of the 

6 channel; and 

7 d) selectively displaying, via the information distribution centers and in 

8 accordance with non-geographic criteria, the non-meteorological products to 

9 provide video programming specific to each of the locales. 

1 3. The method of claim 1 in which the step of dynamically scheduling the transmissions 

2 further comprises maintaining a record of all products sent to each distribution center 

3 and a schedule of activities for each distribution center. 

1 4. A method for distributing video programming to a plurality of cable service providers 

2 comprising the steps of: 
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b) 



a) formatting the programming so that it comprises: 

i) a first portion to be utilized by- all of the providers; and 

ii) a second portion which further comprises a plurality of data subsets, in 
which selected data subsets are to be utilized by selected providers and 
in which the data subsets contain at least one address based on non- 
hierarchical criteria; 

programming receivers resident with each of the providers to be responsive to 
the non-hierarchical criteria; 

c) distributing the first portion and the second portion to the providers; 

d) reading the addresses of the data subsets; 

e) selecting data subsets in accordance with the non-hierarchical criteria; and 
0 periodically utilizing the selected data subsets. 

The method of claim 4 further comprising the step of passing the first portion cable 
viewers. 

The method of claim 4 in which the step of utilizing the selected data subsets further 
comprises the steps of: 

a) formatting the data; 

b) incorporating the formatted data in video effects; and 

c) periodically interposing the formatted, incorporated data to the redistribution 
system. 

The method of claim 4 in which the step of utilizing the selected data subsets further 
comprises the step of re-programming the receiver with software included in the data 
subset. 



The method of claim 4 in which the step of utilizing the selected data subsets further 
comprises the step of performing housekeeping functions to maintain the receiver. 
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1 9. The method of claim 8 in which the step of performing housekeeping functions 

2 further comprises the step ofperforming system diagnostics. 

1 10. The method of claim 8 in which the step of performing housekeeping functions 

2 further comprises the step of maintaining a dynamic inventory. 

1 11. A method for distributing and utilizing a plurality of data packets comprising the steps 

2 of: 

3 a) formatting the data packets so that each includes at least one non-hierarchical 

4 address and a priority marker; 

5 b) posting the data packets on a posting queue; 

6 c) requesting via a host requester the data packets posted on the posting queue; 

7 d) posting the requested data packets to a selected one of a plurality of queue 

8 server queues; 

9 e) selecting the data packets from the queue server queues on the basis of the 

10 priority marker; 

1 1 f) transmitting the information to a receiving unit; 

12 g) reading the non-hierarchical address of each data packet and selecting those 

13 data packets bearing a non-hierarchical address which corresponds to an 

14 interest list; and 

1 5 h) utilizing the selected data packets. 

1 1 2. The method of claim 1 1 in which the step of utilizing the selected data packets further 

2 comprises the steps of: 

3 a) formatting the selected data packets; 

4 b) incorporating the formatted selected data packets in video effects; and 

5 c) periodically forwarding the formatted, incorporated selected data packets to a 

6 redistribution system. 
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The method of claim 1 1 in which the step of utilizing the selected data packets further 
comprises the step of replacing on-board receiving unit software with software 
included in the selected data packets. 

The method of claim 1 1 in which the step of utilizing the selected data packets further 
comprises the step of performing receiving unit housekeeping functions. 

The method of claim 14 in which the step of perform.ng receiving unit housekeeping 
functions further comprises the step of performing system diagnostics. 

The method of claim 14 in which the step of performing receiving unit housekeeping 
functions further comprises the step of maintaining a dynamic inventory. 



A system for distributing information to a plurality of receivers in which the 
information comprises a first portion to be received and processed by all of the 
receivers, a second portion which further comprises a plurality of combined data 
subsets each having a first address packet and a data packet, in which selected 
combined data subsets may be addressed to selected receivers and a third portion 
which further comprises a plurality of bifurcated data subsets, each having a second 
address packet and an associated data stream, in which selected bifurcated data 
subsets may be addressed to selected receivers, the system comprising: 
9 a) a production system responsive to an automation system and which transmits 

the first portion and the data streams of the third portion through a first 
1 J channel; 

12 b) a host responsive to the automation system, and which transmits the second 

1 3 portion and the address packets of the third portion through a second channel; 

14 i) in which each receiver receives the first portion and delivers it to a 
' ^ corresponding re-distributing system; 
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1 6 ii) in which each receiver receives the second portion and, if the first 

17 address packet of one of the combined data subsets corresponds to an 
1 8 address of a particular receiver, the particular receiver periodically 

19 selectively interrupts delivery of the first portion and processes and 

20 delivers the data packet of the one of the combined data subsets to the 

21 corresponding re-distributing system; 

22 iii) in which each receiver receives the third portion and if the second 

23 address packet of one of the bifurcated data subsets corresponds to the 

24 address of a particular receiver, the particular receiver receives the data 

25 stream associated with the address packet; and 

26 c) a dynamic scheduler which coordinates the transmission of the data stream and 

27 the second address packet of the third portion, the dynamic scheduler further 

28 comprising a record of all information sent to each receiver and a schedule of 

29 functions to be performed by each of the receivers. 

1 1 8. The system of claim 1 7 in which the receiver passes the data stream through to the 

2 redistribution system. 

19. The system of claim 17 in which the receiver stores and processes the data stream. 

1 20. The system of claim 1 7 further comprising a two-way communication link between 

2 and the receiver through which the scheduler queries the receiver in order to create the 

3 record, 

1 21 . The system of claim 17 in which the scheduler creates the record by maintaining a 

2 record of all information transmitted to the receiver and all scheduling commands 

3 transmitted to the receivers. 

1 22. A method for distributing information to a plurality of receivers comprising the steps 

2 of: 
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a) proving a first portion of the information to be received and processed by 

4 of the receivers; 

5 b ) providing a second portion of the information which further comprises a 

6 plurality of combined data subsets each having a first address packet and a 

7 data packet, in which selected combined data subsets may be addressed to 

8 selected receivers; 

9 c) providing a third portion of the information which further comprises a 

10 plurality of bifurcated data subsets, each having a second address packet and 

1 1 an associated data stream, in which selected bifurcated data subsets may be 

12 addressed to selected receivers; 

1 3 d) transmitting the first portion and the data streams of the third portion through 

'4 first channel; 

1 5 e) transmitting the second portion and the address packets of the third portion 

1 6 through a second channel; 

1 7 f) receiving the first portion and delivering the first portion to a corresponding 

1 8 re-distributing system; 

1 9 g) receiving the second portion and, responsive to a schedule, periodically 

20 selectively interrupting delivery of the first portion and processing and 

2 1 delivering the one of the combined data subsets to the corresponding re- 

22 distributing system; 

23 h) receiving the third portion and, responsive to the schedule, periodically 

24 selectively utilizing the data stream associated with the address packet; 

25 ' } coordinating transmission of the first, second and third portions to ensure that 

26 the data stream is transmitted in coordination with the address packet of the 

27 third portion; 

28 J) creating a first record of all of the information transmitted to each of the 

29 receivers; 

30 k > creating a second record of the schedule for each receiver; and 

3 1 1} coordinating the transmissions in accordance with the first and second records 

32 to optimize the utilization of the first and second channels. 
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1 23. The method of claim 22 in which the first and second records are created by querying 

2 each receiver. 

1 24. The method of claim 22 in which the first and second records are created by recording 

2 all transmissions to each receiver. 

1 25. The system of claim 22 in which the step of utilizing the data stream comprises 

2 passing the data stream through to the corresponding re-distributing system. 

1 26. The system of claim 22 in which the step of utilizing the data stream comprises 

2 storing and processing the data stream. 

1 27. A system for delivering a command stream from a host to an addressable receiver 

2 over a selected one of a plurality of communications channels comprising; 

3 a) a communications protocol overlay connected to the host; and 

4 b) a communications protocol underlay connected to the overlay which 

5 communicates with the addressable receiver over the selected channel and 

6 provides the protocol which allows the host to communicate over the selected 

7 channel. 

1 28. The system of claim 27 in which the communications channels comprise at least a 

2 TCP/IP line, an RS-232 line and a one-way wireless transmission channel. 

1 29. A method for utilizing data having an address, comprising the steps of: 

2 a) comparing the address to an interest list and, if the address matches the interest 

3 list, determining whether the data is an application or product data; 

4 b) forwarding product data to a presentation engine and formatting the product 

5 data for presentation; and 



68 



BNSDOCID: <WO 9815122A1 J_> 



WO 98/15122 



PCT/US97/174I2 



6 c) forwarding applications to a hardware abstraction layer which utilizes the 

7 application to perform system management tasks. 

I 30. A presentation system for presenting weather related information, the presentation 

. 2 system comprising a transmission system which distributes data to a plurality of 

3 addressable receivers, each of which receivers process and deliver selected portion 

4 the data to a re-distribution system, the receivers being adapted to analyze the data 

5 and, responsive to criteria stored within the receivers, generate and present pre- 

6 selected products which where not requested or instructed by the transmission syst< 

31. The system of claim 30 in which the receivers are programmed with the criteria. 

32. The system of claim 30 in which the receivers are trained with the criteria. 

1 33. The system of claim 30 in which the pre-selected criterion is the intensity levels of 

2 radar image pixels. 

1 34. The system of claim 33 in which the data is reformatted to include a warning 

2 consistent with the intensity level. 

1 35. The system of claim 30 in which the pre-selected criterion is the absence data in a 

2 selected field. 

1 36. The system of claim 30 in which the pre-selected criteria is the absence of a signal 

2 from the transmission system. 

1 37. The system of claim 30 in which the pre-selected criteria is a reset signal from the 

2 transmission system. 
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1 38. A process for providing programming for processing by a plurality of headend units, 

2 comprising the steps of: 

3 a) providing a plurality of video sources each of which supplies at least one video 

4 output signal; 

5 b) providing a plurality of data sources each of which supplies at least one data 

6 output signal; 

7 c) providing a host adapted to operate on the at least one data output signal; 

8 d) providing an automation system adopted to operate on the plurality of video 

9 sources; 

10 e) providing a headend address source adapted to supply at least one headend 

1 1 address signal to the host; 

12 t) providing a sales interface adapted to supply at least one sales information 

13 signal to the address source; 

14 g) utilizing said at least one data output signal, said automation signal, said host, 

15 said at least one headend address signal and said at least one sales information 

16 signal, to construct at least one programming signal comprising data from said 

17 at least one data output signal ordered and addressed according at least in part 

18 to said headend address signal; and 

19 h) modulating said programming signal onto a radiofrequency signal for 

20 transmission to said headend units via satellite transponder. 

1 39. The process of claim 38 further comprising the steps of providing a master dynamic 

2 scheduler; and utilizing said at least one video output signal, said host, the master 

3 dynamic scheduler and said at least one headend address signal to construct at least 

4 one programming signal comprising video from said at least one video output signal 

5 ordered and addressed according at least in part to said headend address signal. 

40. The process of claim 39 in which a plurality of programming signals are constructed. 
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1 41 Apparatus for providing programming for processing by a plurality of headend units. 

2 comprising: 

3 a) a plurality of video sources each of which is adapted to supply at least one 

4 video output signal; 

5 b) a plurality of data sources each of which is adapted to supply at least one data 

6 output signal; 

7 c) a headend address source adapted to supply at least one headend address 

8 signal; 

9 d) a sales interface adapted to supply at least one sales information signal to the 
' 0 head end address source; 

11 e) a host ^apted to operate on said at least one video output signal and said at 

12 least one data o^put signal utilizing said at least one headend address signal to 

1 3 construct at least one programming signal comprising video from said at least 

1 4 one video out P ut s 'g na l and data from said at least one data output signal, said 

1 5 video and said da ta ordered and addressed in said programming signal at least 

1 6 in P art according to information contained in said at least one headend address 

17 signal; and 

1 8 0 radiofrequency modulation circuitry adapted to modulate said at least one 

1 9 programming signal onto at least one radiofrequency signal for transmission 

20 via satellite to said headend units. 

1 42. Apparatus according to claim 4 1 in which said plurality of video sources includes at 

2 least one digital video source. 

1 43. Apparatus according to claim 41 in which said plurality of video sources includes at 

2 least one video content storage device. 
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1 44. Apparatus according to claim 41 in which said plurality of video sources includes at 

2 least one studio to provide video signals in real time for inclusion in said 

3 programming signals. 

1 45. Apparatus according to claim 41 in which said plurality of data sources includes at 

2 least one server adapted to output graphics content signals. 

1 46. Apparatus according to claim 41 in which said plurality of data sources includes at 

2 least one source adapted to output digital video content signals. 

1 47. Apparatus according to claim 41 in which said plurality of data sources includes at 

2 least one source adapted to receive, store, process and output data from a plurality of 

3 geographical locations. 

1 48. Apparatus according to claim 47 in which said data from a plurality of geographical 

2 locations comprises meteorological data. 

1 49. Apparatus according to claim 41 in which said host is adapted to construct said at 

2 least one programming signal according to at least one predetermined schedule. 

1 50. Apparatus according to claim 41 in which said radiofrequency modulation circuitry is 

2 adapted to output a plurality of subcamer signals, at least one of which contains 

3 ordered and addressed data programming, and at least one of which contains video 

4 programming. 

1 51. Apparatus for providing programming for processing by a plurality of headend units, 

2 comprising: 

3 a) a plurality of video sources each of which is adapted to supply at least one 

4 video output signal; 
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b) a plurality of data sources each of which is adapted to supply at least one data 
output signal; 

c) a headend address source adapted to supply at least one headend address 
signal; 

d) a scheduling interface adapted to supply at least one scheduling signal; 

e) a host adapted to operate on said at least one video output signal and said at 
least one data output signal utilizing said at least one scheduling signal and 
said at least one headend address signal to construct at least one programming 
signal comprising video from said at least one video output signal and data 
from said at least one data output signal, said video and said data ordered and 
addressed in said programming signal at least in part according to information 
contained in said at least one scheduling signal, said at least one headend 
address signal; and 

0 radiofrequency modulation circuitry adapted to modulate said at least one 

programming signal onto at least one radiofrequency signal for transmission 
via satellite to said headend units. 

Apparatus according to claim 5 1 in which said plurality of data sources includes at 
least one source adapted to receive, store, process and output data from a plurality of 
geographical locations. 

Apparatus according to claim 51 in which said radiofrequency modulation circuitry is 
adapted to output a plurality of subcarrier signals, at least one of which contains 
ordered and addressed data programming, and at least one of which contains video 
programming. 

Apparatus according to claim 5 1 in which the headend units each are located at a 
headend location, at least some of which headend locations are located geographically 
apart from other headend locations, each headend unit further comprising: 
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4 a) demodulation circuitry for receiving signals via satellite units from said 

5 apparatus for providing programming and for providing for output headend 

6 programming signals; 

7 b) processing circuitry for identifying, storing and processing for display at least 

8 some of the data in said headend programming signals containing addresses 

9 which corresponds to an interest list stored in the headend unit that comprises 
10 at least one address corresponding to said headend unit; and 

1 ] c) circuitry adapted to process for display in real time at least some of the video 

12 in at least one of said headend programming signals. 

1 55. Apparatus according to claim 54 in which said processing circuitry is adapted to 

2 receive, store and process headend unit control signals from said apparatus for 

3 providing programming in order to vary the manner in which said processing circuitry 

4 identifies, stores and processes for display at least some of the data in said headend 

5 programming signals. 

1 56. Apparatus according to claim 54 in which said processing circuitry is adapted to 

2 receive, process and store interest list signals from said apparatus for providing 

3 programming signals in order to vary the programming signals that are stored and 

4 processed by said headend unit. 

1 57. Apparatus according to claim 54 further comprising at least one telecommunications 

2 system interface for receiving control signals and data from non-radiofrequency 

3 sources, processing said signals, and providing at least some of said signals to said 

4 processing circuitry for varying the manner in which said processing circuitry 

5 identifies, stores and processes for display at least some of the data in said headend 

6 programming signals. 

1 58. Apparatus according to claim 54 further comprising at least one telecommunications 

2 system interface for receiving control signals and data from radiofrequency sources, 
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processing said s lg nals. and providing at least some of said signals to said processing 

4 circuitry for varying the manner in which said processing circuitry identifies, stores 

5 and processes for display at least some of the data in said headend programming 

6 signals. 



1 59 

1 



Apparatus according to claim 58 in which said at least one telecommunications 
system interface provides correction to the global information infrastructure and is 
3 adapted to accommodate protocol employed in said infrastructi 



1 61. 

9 



I 63. 

2 

3 

4 

1 64. 



ture. 



2 
3 



60. Apparatus according to claim 58 in which said at least one telecommunications 
system interface provides connection to the public switched telephone network. 



Apparatus according to claim 58 in which said at least one telecommunications 
system interface is adapted to accommodate asynchronous communications. 



1 62. Apparatus according to claim 54 in which said headend unit components share 

2 common interface standards. 



65. 



Apparatus according to claim 54 in which said headend unit processing circuitry is 
adapted to assemble, using at least certain control information received from said 
apparatus for providing programming.signals, video programming for output, 
comprising video and data from said headend programming signals. 

Apparatus according to claim 54 in which said apparatus for providing programming 
signals is adapted to provide, and said headend units are adapted to receive, store and 
process, data objects which are adapted to create graphic programming. 

Apparatus according to claim 54 in which said apparatus for providing programming 
signals is adapted to provide, and said headend units are adapted to receive, store and 
process, data objects which are adapted to create video programming. 
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1 70. Apparatus according to claim 67 further comprising at least one telecommunications 

2 system interface for receiving control signals and data from non-radiofrequency 

3 sources, processing said signals, and providing at least some of said signals to said 

4 headend unit processing circuitry for varying the manner in which said processing 

5 circuitry identifies, stores and processes for display at least some of the data in said 

6 headend programming signals. 

1 71 . Apparatus according to claim 67 further comprising at least one telecommunications 

2 system interface for receiving control signals and data from radiofrequency sources, 

3 processing said signals, and providing at least some of said signals to said headend 

4 unit processing circuitry for varying the manner in which said processing circuitry 

5 identifies, stores and processes for display at least some of the data in said headend 

6 programming signals. 

1 72. Apparatus according to claim 70 in which said at least one telecommunications 

2 system interface provides connection to the global information infrastructure and is 

3 adapted to accommodate protocol employed in said infrastructure. 

1 73. Apparatus according to claim 70 in which said at least one telecommunications 

2 system interface provides connection to the public switched telephone network. 

1 74. Apparatus according to claim 70 in which said at least one telecommunications 

2 system interface is adapted to accommodate asynchronous communications. 

1 75. Apparatus according to claim 67 in which said headend unit processing circuitry is 

2 adapted to assemble, using at least certain control information received from said 

3 control site apparatus, and from said headend programming signals, video 

4 programming for output, comprising video and data from said headend programming 

5 signals. 
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1 76. 
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I 77. 
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1 78. 
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1 79. 

3 
4 

5 



Apparatus according to claim 67 in which said control site apparatus 1S adapted to 
prov.de. and said headend units are adapted to receive, store and process, data objects 
which are adapted to create graphic programming. 

Apparatus according to Cairn 67 in which sa,d contro. site apparatus is adapted to 
prov.de, and said headend units are adapted to recede, store and process, data ob,ects 
which are adapted to create video programming. 

Apparatus according to claim 67 in which said control s.te apparatus is adapted to 
provide, and said headend units are adapted to receive, store and process, executable 
computer program objects which are adapted to vary the manner in which said 
headend processing circu.try identifies, stores and processes for display at least some 



5 of said headend programming signals. 



Apparatus according to claim 67 further comprising at least one queue storage devices 
for receiving and storing video products contained in said video output signal from 
said at least one video output sources and data products contained in said data output 
signal from said at least one data sources, and upon request, outpurting said products 
for construction of said programming signal. 



1 80. Apparatus according to claim 79 in which said request signal is a function of said 

2 scheduling signal. 

1 81. Apparatus according to claim 67 in which the headend units are located the homes of 

2 end users and receive signals at the user's home from a satellite. 

1 82. Apparatus according to claim 67 in which the headend units are located at the homes 

2 of cable operators. 
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1 83. Apparatus according to claim 81 in which said interest lists contain information 

2 corresponding to the postal code of the end user. 

1 84. Apparatus according to claim 81 in which said interest lists contain information 

2 corresponding to the demographics of the end user. 

1 85: Control site apparatus for providing programming for processing by a plurality of 

2 headend units, comprising a plurality of video sources each of which is adapted to 

3 supply, to at least one queue, at least one video product; a plurality of data sources 

4 each of which is adapted to supply to said at least one queue/at least one data product; 

5 a headend address source adapted to supply at least one headend address signal; a 

6 scheduling interface adapted to supply at least one scheduling signal; a controller 

7 adapted to generate and deliver to said at least one queue request signals based on at 

8 least one of the group selected from said headend address signal, said sales 

9 information sigpal and said headend address signal in order to construct at least one 

10 programming signal comprising at least some of said products, each product ordered 

1 1 in said programming signal and addressed based at least in part upon the signals 

12 employed as a basis for generating the request signal for said product. 

1 86. Control site apparatus according to claim 85 adapted to generate and deliver to said 

2 queue request signals based upon said sales interface signals in order to generate and 

3 make available to selected headend units customized advertising products. 

1 87. Control site apparatus according to claim 85 adapted to generate and deliver to said 

2 queue request signals based upon said sales interface signals and said scheduling 

3 signals in order to generate and make available to selected headend units customized 

4 advertising products. 



80 



BNSDOCID: <WO 9815122A1J_> 



WO 98/15122 



PCT/US97/17412 



1 88. 



4 products 



Control site apparatus according ,o claim 85 adapted to generate and deliver to said 
queue request stgnals based upon scheduling signals in order to generate and make 
ava,lab,e to seiected headend units programing conlaini „ E customiMd informa 
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